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Intellectual Property Rights 
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pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ETSI Project Broadband Radio Access Networks (BRAN). 

The present document describes the supplemental data transport and radio control functions of the Data Link Control 
(DLC) of High PErformance Radio Metropolitan Area Network (HiperMAN) systems. A separate ETSI document, 
TS 102 177 [2], specifies the Physical (PHY). 

With permission of IEEE® (on file as BRAN43d016), portions of the present document are excerpted from IEEE 
Standards [1], [3] and [4]. 



ETSI 



ETSI TS 102 178 VI .3.1 (2006-02) 



Scope 



The present document defines the Data Link Control (DLC) of HiperMAN to support PMP and optionally Mesh 
network topologies. The present document provides the DLC functions required for Fixed applications, in frequencies 
below 1 1 GHz, and Nomadic and converged Fixed-Nomadic applications, in frequencies below 6 GHz. 
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Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 
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Part 16: Air Interface for Fixed and Mobile Broadband Wireless Access Systems - Amendment for 
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3 Definitions, symbols and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

Adaptive Antenna System (AAS): system adaptively exploiting more than one antenna to improve the coverage and 
the system capacity 

NOTE: AAS-enabled in the context of a PMP BS denotes the implementation of AAS as defined. AAS-enabled 
in the context of a PMP SS denotes the ability to communicate with an AAS-enabled BS using the AAS 
specific mechanisms. Though a PMP SS may itself implement AAS as defined, this has no impact on the 
air interface and hence no specific differentiation is made. 

adaptive modulation: system's ability to communicate with another system using multiple burst profiles and a system's 
ability to subsequently communicate with multiple systems using different burst profiles 
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ARQ Block: distinct unit of data that is carried on an ARQ-enabled connection 



NOTE: Such a unit is assigned a sequence number, and is managed as a distinct entity by the ARQ state 
machines. 

broadcast connection: management connection used by the Base Station (BS) to send Data Link Control (DLC) 
management messages on a downlink to all Subscriber Station (SS) 

NOTE: The broadcast connection is identified by a well-known Connection IDentifier (CID). A fragmentable 

broadcast connection is a connection that allows fragmentation of broadcast DLC management messages. 

bandwidth stealing: use, by a subscriber station operating on a grant per subscriber station basis, of a portion of the 
bandwidth allocated in response to a bandwidth request for a connection to send a bandwidth request or data for any of 
its connections 

NOTE: See also: grant per subscriber station. 

connection: unidirectional mapping between Base Station (BS) and Subscriber Station (SS) Data Link Control (DLC) 
peers 

NOTE: Connections are identified by a Connection IDentifier (CID). The DLC defines two kinds of connections: 
management connections and transport connections. See also: connection identifier. 

Connection IDentifier (CID): 16-bit value that identifies a transport connection or an uplink (UL)/downlink (DL) pair 
of associated management connections (i.e. belonging to the same subscriber station) to equivalent peers in the DLC of 
the Base Station (BS) and Subscriber Station (SS) 

NOTE: The Connection IDentifier (CID) address space is common (i.e. shared) between UL and DL and 
IEEE 802.16 [1], table 345 specifies how it is partitioned among the different types of connections. 
Security Associations (SAs) also exist between keying material and CIDs. See also: connection. 

DC carrier: in an OFDM or OFDMA signal, the carrier whose frequency would be equal to the RF centre frequency of 
the station 

Dynamic Frequency Selection (DFS): ability of a system to switch to different physical RF channels based on channel 
measurement criteria to conform to particular regulatory requirements 

initial ranging connection identifier: management connection used by the Subscriber Station (SS) and the Base 
Station (BS) during the initial ranging process 

NOTE: The initial ranging connection is identified by a well-known Connection IDentifier (CID) (see 

IEEE 802.16 [1], table 345). This CID is defined as constant value within the protocol since an SS has no 
addressing information available until the initial ranging process is complete. 

management connection: connection used for the purpose of transporting Data Link Control (DLC) management 
messages (see: basic connection, primary management connection, broadcast connection, initial ranging connection) or 
standards-based messages (see: secondary management connection) required by the DLC layer 

MeSH (MSH): network architecture, wherein systems are capable of forwarding traffic from and to multiple other 

systems 

Multiple Input Multiple Output (MIMO): system employing at least two transmit antennas and at least two receive 
antennas to improve the system capacity, coverage or throughput 

Payload Header Suppression Mask (PHSM): 8 bit value that references the Payload Header Suppression (PHS) rule 

Quality of Service (QoS) parameter set: Is associated with a Service Flow IDentifier (SFID). The contained traffic 
parameters define scheduling behavior of uplink or downlink flows associated with transport connections. 

RF centre frequency: centre of the frequency band in which a BS or SS is intended to transmit 
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BS Rx/Tx Transition Gap (RTG): gap, used by TDD and H-FDD systems, between the last sample of the uplink burst 
and the first sample of the subsequent downlink burst at the antenna port of the base station in a time division duplex 
transceiver 

NOTE: This gap allows time for the BS to switch from receive to transmit mode and SSs to switch from transmit 
to receive mode. During this gap, the BS is not transmitting modulated data but simply allowing the BS 
transmitter carrier to ramp up, the Tx/Rx antenna switch to actuate. Not applicable to frequency division 
duplex systems. 

SS Rx/Tx Gap (SSRTG): the minimum receive to transmit turnaround gap 

NOTE: SSRTG is measured from the time of the last sample of the received burst to the first sample of the 
transmitted burst, at the antenna port of the SS. 

SS Tx/Rx Gap (SSTTG): the minimum transmit to receive turnaround gap 

NOTE: SSTTG is measured from the time of the last sample of the transmitted burst to the first sample of the 
transmitted burst, at the antenna port of the SS. 

turbo decoding: iterative decoding, using soft inputs and soft outputs 

BS Tx/Rx Transition Gap (TTG): gap, used by TDD and H-FDD systems, between the last sample of the downlink 
burst and the first sample of the subsequent uplink burst at the antenna port of the base station in a time division duplex 
transceiver 

NOTE: This gap allows time for the BS to switch from transmit to receive mode. During this gap, the BS is not 
transmitting modulated data but simply allowing the BS transmitter carrier to ramp down, the Tx/Rx 
antenna switch to actuate, and the BS receiver section to activate. Not applicable to frequency division 
duplex systems. 

transport connection: connection used to transport user data 

NOTE: It does not include any traffic over the basic, primary or secondary management connections. A 

fragmentable transport connection is a connection that allows fragmentation of Service Data Units 
(SDUs). 

transport connection identifier: unique identifier taken from the Connection IDentifier (CID) address space that 
uniquely identifies the transport connection 

NOTE: All user data traffic is carried on transport connections, even for service flows that implement 

connectionless protocols, such as Internet Protocol (IP). An active or admitted service flow (identified by 
a Service Flow ID (SFID)) maps to a transport Connection IDentifier (transport CID) assigned by the BS. 

3.2 Symbols 

For the purposes of the present document, the following symbols apply: 

a Averaging parameter for CINR and RSSI computations 

RSS^ jjjj^x Initial Ranging Max. Received Signal Strength at BS 

3.3 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

A AS Adaptive Antenna System 

AMC Adaptive Modulation Coding 

ARQ Automatic Repeat reQuest 

BS Base Station 

BTC Block Turbo Code 

BW Bandwidth 

CID Connection IDentifier 

CINR Carrier to noise and INterference Ratio 
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CS Convergence Sublayer 

CSCF Centralized Scheduling ConFiguration 

CSCH Centralized SCHedule 

CTC Convolutional Turbo Code 

dBm Decibels relative to one milliwatt 

DCD DL Channel Descriptor 

DPS Dynamic Frequency Selection 

DIUC Downlink Interval Usage Code 

DL DownLink 

DLC Data Link Control 

DSA-RSP Dynamic Service Addition - ReSPonse 

DSCH Distributed SCHedule 

DSC-REQ Dynamic Service Change - REQuest 

DSC-RSP Dynamic Service Change - ReSPonse 

FDD Frequency Division Duplexing 

FPC Fast Power Control 

FWA Fixed Wireless Access 

HCS Header Check Sequence 

H-FDD Half-duplex FDD 

ID IDentifier 

IE Information Element 

Im Imaginary 

IP Internet Protocol 

LOS Line Of Sight 

MAC Media Access Control 

MIMO Multiple Input Multiple Output 

msb most significant bit 

MSH MeSH 

NCFG Network ConFiGuration 

NENT Network ENTry 

OFDM Orthogonal Frequency Division Multiplexing 

OFDMA Orthogonal Frequency Division Multiple Access 

PHS Payload Header Suppression 

PHSM Payload Header Suppression Mask 

PHY PHYsical layer 

PKM Privacy Key Management 

PMP Point-to-MultiPoint 

PUSC Partial Usage of Subchannels 

QoS Quality of Service 

Re Real 

REQ REQuest 

RNG RaNGing 

RSP ReSPonse 

RSSI Received Signal Strength Indicator 

RTG Receive/transmit Transition Gap 

SA Security Association 

SDU Service Data Unit 

SFID Service Flow IDentifier 

SS Subscriber Station 

STC Space Time Coding 

TEK Traffic Encryption Key 

TLV Type Length Value 

TTG Transmit/receive Transition Gap 

UCD UL Channel Descriptor 

UDP User Datagram Protocol 

UIUC Uphnk Interval Usage Code 

UL UpLink 
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Packet Convergence Sublayer 



The packet Convergence Sublayer (CS) resides on top of the IEEE Std 802.16 MAC CPS. The CS performs the 
following functions, utilizing the services of the DLC: 

a) Classification of the higher-layer protocol PDU into the appropriate transport connection. Suppression of 
payload header information (optional). 

b) Delivery of the resulting CS PDU to the DLC SAP associated with the service flow for transport to the peer 
DLC SAP. 

c) Receipt of the CS PDU from the peer DLC SAP. 

d) Rebuilding of any suppressed payload header information (optional). 

The sending CS is responsible for delivering the DLC SDU to the DLC SAP. The DLC is responsible for delivery of the 
DLC SDU to peer DLC SAP in accordance with the QoS, fragmentation, concatenation and other transport functions 
associated with a particular connection's service flow characteristics. The receiving CS is responsible for accepting the 
DLC SDU from the peer DLC SAP and delivering it to a higher layer entity. 

The packet CS is used for transport for all packet-based protocols as defined in IEEE 802.16 [1], clause 1 1.13.19.3 as 
modified by IEEE P802.16/Corl [3] and IEEE P802.16e [4]. 

4.1 DLC SDU format 

DLC SDU format is according to IEEE 802.16 [1], clause 5.2.1 as modified by IEEE P802.16/Corl [3] and 
IEEEP802.16e[4]. 

4.2 Classification 

Packet classification is according to IEEE 802.16 [1], clause 5.2.2 as modified by IEEE P802.16/Corl [3] and 
IEEEP802.16e[4]. 

4.3 Payload Header Suppression (PHS) 

Payload Header Suppression is according to IEEE 802.16 [1], clause 5.2.3 as modified by IEEE P802.16/Corl [3] and 
IEEEP802.16e[4]. 

4.4 Ethernet specific part 

Ethernet specific part is according to IEEE 802.16 [1], clause 5.2.4 as modified by IEEE P802.16/Corl [3] and 
IEEEP802.16e[4]. 

4.5 Virtual local area network (VLAN) specific part 

Virtual local area network specific part is according to IEEE 802.16 [1], clause 5.2.5 as modified by 
IEEEP802.16/Corl [3] and IEEE P802.16e [4]. 



4.6 IP specific part 



IP specific part is according to IEEE 802.16 [1], clause 5.2.6 as modified by IEEE P802.16/Corl [3] and 
IEEEP802.16e[4]. 
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5 DLC common part sublayer 

5.1 Point to Multi Point 

Point to Multi Point is according to IEEE 802.16 [1], clause 6.1 as modified by IEEE P802.16/Corl [3] and 
IEEEP802.16e[4]. 

5.2 IVIesh 

Mesh is according to IEEE 802.16 [1], clause 6.2 as modified by IEEE P802.16/Corl [3] and IEEE P802.16e [4]. 



Data/Control plane 



The data/control plane is according to IEEE 802.16 [1], clause 6.3 as modified by IEEE P802.16/Corl [3] and 
IEEEP802.16e[4]. 



7 PDU formats 



DLC PDUs shall be of the form illustrated in figure 1. Each PDU shall begin with a fixed-length generic DLC header. 
The header may be followed by the Payload of the DLC PDU. If present, the Payload shall consist of zero or more 
subheaders and zero or more DLC SDUs and/or fragments thereof. The payload information may vary in length, so that 
a DLC PDU may represent a variable number of bytes. This allows the DLC to tunnel various higher layer traffic types 
without knowledge of the formats or bit patterns of those messages. All reserved fields shall be set to zero on 
transmission and ignored on reception. 

msb Isb 



Generic MAC header 


Payload (optional) 


CRC (optional) 



Figure 1 : DLC PDU formats 

A DLC PDU may contain a CRC, In the case where a CRC is included, for each DLC PDU with HT=0, a CRC, as 
defined in IEEE 802.3 [5], shall be appended to the payload of the DLC PDU; i.e., request DLC PDUs are unprotected. 
The CRC shall cover the generic DLC header and the Payload of the DLC PDU. The CRC shall be calculated after 
encryption; i.e. the CRC protects the Generic Header and the ciphered Payload. Implementation of CRC capability is 
mandatory. 

7.1 DLC header formats 

Two DLC header formats are defined. The first is the generic DLC header that begins each DLC PDU containing either 
DLC management messages or CS data. The second is the bandwidth request header used to request additional 
bandwidth. The single-bit Header Type (HT) field distinguishes the generic DLC header and bandwidth request header 
formats. The HT field shall be set to zero for the Generic Header and to one for a bandwidth request header. 

The generic DLC header format is defined in table 1 . 
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Syntax 


Size 


Notes 


MAC Header () { 






HT 


1 bit 


ObO = Generic DLC header 
Obi = Bandwidth request header 


EC 


1 bit 


if HT = 0b1, EC = ObO 


if (HT == 0) { 






Type 


6 bits 




reserved 


1 bit 


Shall be set to ObO 


CI 


1 bit 




EKS 


2 bits 




reserved 


1 bit 


Shall be set to ObO 


LEN 


1 1 bits 




] else { 






Type 


3 bits 




BR 


19 bits 




} 
CID 


16 bits 




HCS 


8 bits 




} 







CI 



CID 



EC 



EKS 



HCS 



HT 



LEN 



Type 



CRC indicator. Ob 1 = CRC is included in the PDU by appending it to the PDU payload after encryption, if 
any. ObO = CRC is not included. 



Connection identifier. 



Encryption control. ObO = Payload is not encrypted. Obi = Payload is encrypted. 



Encryption Key Sequence. The index of the Traffic Encryption Key (TEK) and Initialization Vector used to 
encrypt the payload. This field is only meaningful if the EC field is set to 1 . 

Header check sequence. An 8 -bit field used to detect errors in the header. The transmitter shall calculate the 
HCS value for the first five bytes of the cell header, and insert the result into the HCS field (the last byte of the 
DLC header). It shall be the remainder of the division (Modulo 2) by the generator polynomial 
g(D)=D8+D2+D+l of the polynomial Ds multiplied by the content of the header excluding the HCS field. 
(Example: [HT EC Type]=0x80, BR=OxAAAA, CID=OxOFOF; HCS should then be set to OxD5). 



Header type. Shall be set to zero. 

The length in bytes of the DLC PDU including DLC header and CRC, if present. 

Indicates the subheaders and special payload types are present in the message payload. 



7.2 DLC header type encodings 
7.2.1 Type encodings 

The Type field in the Generic DLC Header shall indicate the presence of subheaders and payload as shown in table 2. 
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Table 2: Type encodings 



Type bit 


Value 


#0 (Isb) 


UL: Grant Management Subheader 

DL: FAST-FEEDBACK allocation subheader 

1 = present, = absent 


#1 


Packing Subheader 
1 = present, = absent 


#2 


Fragmentation Subheader 
1 = present, = absent 


#3 


Extended Type indicates whether the present 

Packing/Fragmentation Subheader is extended. 

1 = extended, = not extended 

For ARQ enabled connections, this bit shall be set 

toOb1 


#4 


ARQ Feedback Payload 
1 = present, = absent 


#5 (msb) 


Mesh Subheader 

1 = present, = absent 



Four types of Subheaders may be present. The per-PDU subheaders (the Mesh subheader, the Fragmentation subheader 
and the Grant Management subheader) may be inserted in DLC PDUs immediately following the Generic DLC. If both 
the Fragmentation Subheader and Grant Management Subheader are indicated, the Grant Management Subheader shall 
come first. If the Mesh Subheader is indicated, it shall precede all other subheaders. 



7.2.2 



Bandwidth request header 



The Bandwidth Request PDU shall consist of bandwidth request header alone and shall not contain a payload. The 
bandwidth request header is illustrated in figure 2. 






'^ 



T>pe(3) 



^-4 



BR MSB (11) 



f-h 



BRLSB(&) 



I I I I I I I 

CID LSB (8) 

I I I I I I I 



I I I I I M 



C:rD MSB (8) 



I I I I I I I 

HCS (S) 

I I I I 






Figure 2: Bandwidth) request hieader format 

The Bandwidth Request shall have the following properties: 

a) The length of the header shall always be 6 bytes. 

b) The EC field shall be set to 0, indicating no encryption. 

c) The CID shall indicate the connection for which uplink bandwidth is requested. 

d) The Bandwidth Request (BR) field shall indicate the number of bytes requested. 
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e) The allowed types for bandwidth requests are "000" for incremental and "001" for aggregate. 

An SS receiving a bandwidth request header on the downlink shall discard the PDU. 

The fields of the bandwidth request header are defined in table 3. Every header is encoded, starting with the HT and EC 
fields. The coding of these fields is such that the first byte of a DLC header shall never have the value of OxFX. This 
prevents false detection of the stuff byte. 

Table 3: Bandwidth request header fields 



Name 


Length 
(bits) 


Description 


BR 


19 


Bandwidth Request: 

The number of bytes of uplink bandwidth requested by the SS. The bandwidth request 

is for the CID. The request shall not include any PHY overhead 


CID 


16 


Connection identifier 


EC 


1 


Always set to zero 


HCS 


8 


Header Check Sequence 


HT 


1 


Header Type = Obi 


Type 


3 


Indicates the type of bandwidth request header 



7.2.3 Header Check Sequence (HCS) encoding 

The transmitter shall calculate the HCS value for the first five octets of the cell header, and insert the result into the 
HCS field (the last octet of the DLC header). It shall be the remainder of the division (Modulo 2) by the generator 
polynomial g(D) = D^+D^+D+l of the polynomial D^ multiplied by the content of the header excluding the HCS field. 

EXAMPLE: [HT EC Type] = 0x80, BR = OxAAAA, CID = OxOFOF; HCS should then be set to OxD5. 



7.3 



DLC subheaders 



7.3.1 



Mesh subheader 



The Mesh subheader as shown in table 4 shall always immediately follow the generic DLC header when operating in 
mesh mode, but shall not be used when operating in PMP mode. 

Table 4: Mesh subheader format 



Syntax 


Size 


Notes 


Mesh Subheader { 






Xmt Node Id 


16 bits 


Node Id of the originating mesh node 


} 







7.3.2 ARQ feedback payload 



If the ARQ feedback payload bit in the DLC Header Type field (see table 2) is set, the ARQ Feedback Payload shall be 
transported. If packing is used, it shall be transported as the first packed payload. See clause 8.L2. Note that this bit 
does not address the ARQ Feedback payload contained inside an ARQ Feedback message. 



£75/ 



17 



ETSI TS 102 178 VI .3.1 (2006-02) 



7.3.3 Fragmentation subheader 

The fragmentation subheader is shown in table 5. 



Table 5: Fragmentation subheader format 



Syntax 


Size 


Notes 


Fragmentation Subheader() { 






Fragmentation Control (FC) 


2 bits 


Indicates the fragmentation state of the payload: 

00 = no fragmentation 

01 = last fragment 

10 = first fragment 

1 1 = continuing (middle) fragment 


if {ARQ enabled Connection) 






BSN 


1 1 bits 


Sequence number of the first block in the current SDU 
fragment 


} else { 






If (Type bit#3 (Extended Type) == 0) 




See table 2 


Fragmentation Sequence Number (FSN) 


1 1 bits 


Sequence number of the current SDU fragment. This 
field increments by one (modulo 2048) for each 
fragment, including unfragmented SDUs. Applicable to 
connections where ARQ is not enabled 


}Else{ 






Fragment Block Sequence Number (FSN) 


3 bits 


Sequence number of the first block in the current SDU 
or SDU fragment. This field shall increment by one 
(modulo 8) for each fragment, including unfragmented 
SDUs. Applicable to connections where ARQ is 
enabled 


} 






Reserved 


3 bits 


Shall be set to ObOOO 


} 







7.3.4 Grant Management subheader 

The Grant Management subheader is two bytes in length and is used by the SS to convey bandwidth management needs 
to the BS. This subheader is encoded differently based upon the type of uplink scheduling service for the connection (as 
given by the CID). The use of this subheader is defined in 6.3.6. The Grant Management subheader is shown in table 9. 
Its fields are defined in table 10. The capability of Grant Management subheader at both BS and SS is optional. 

Table 6: Grant management subheader format 



Syntax 


Size 


Notes 


Grant Management Subheader () { 






if (scheduling service type == UGS) { 






SI 


1 bit 


Slip Indicator 

= No action 

1 = Used by the SS to indicate a slop of uplink grants 
relative to the uplink queue depth 


PM 


1 bit 


Poll-Me 

= No action 

1 = Used by the SS to request bandwidth poll 


reserved 


14 bits 


Shall be set to zero 


} 






ekse { 






PiggyBack Request 


16 bits 




1 






} 







PiggyBack Request 



The number of bytes of uplink bandwidth requested by the SS. The bandwidth request is for the CID. The 
request shall not include any PHY overhead. The request shall be incremental. 
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7.3.5 Packing subheader 

When Packing is used, multiple SDUs may be packed into a single DLC PDU. When packing variable-length DLC 
SDUs, the DLC precedes each one with a Packing subheader as shown in table 7. 

Table 7: Packing subheader format 



Syntax 


Size 


Notes 


Packing SubheaderQ { 






Fragmentation Control 


2 bits 


Indicates the fragmentation state of the payload: 

00 = no fragmentation 

01 = last fragment 

10 = first fragment 

1 1 = continuing (middle) fragment 


if (ARQ enabled connection) { 






BSN 


1 1 bits 


Sequence number of first block in the current SDU 
fragment 


} else { 






If (Type bit#3 == 0){ 




See table 2 


FSN 


1 1 bits 


Sequence number of the current SDU fragment. This 
field increments by one (modulo 2048) for each 
fragment, including unfragmented SDUs. Applicable to 
connections where ARQ is not enabled 


}Else{ 






FSN 


3 bits 


Sequence number of the first block in the current SDU 
fragment. This field shall increment by one (modulo 8) 
for each fragment, including unfragmented SDUs. 
Applicable to connections where ARQ is enabled 


Length 


1 1 bits 


The length in bytes of the DLC SDU or SDU fragment, 
including the length of the Packing Subheader 


} 






1 







7.3.6 FAST-FEEDBACK allocation subheader 

The format of the FAST-FEEDBACK allocation subheader is specified in table 8. The FAST-FEEDBACK allocation 
subheader, when used, shall always be the last per-PDU subheader as specified in IEEE 802.16 [1], clause 6.3.2.2. The 
support of the FAST-FEEDBACK allocation subheader is PHY specification specific. 

Table 8: FAST-FEEDBACK allocation header format 



Syntax 


Size 


Notes 


FAST-FEEDBACK allocation Subheader { 






Allocation offset 


6 bits 




Feedback type 


2 bits 


ObOO - Fast DL measurement 

ObOl - Fast MIMO feedback, antenna #0 

Obi - Fast IVIIMO feedback, antenna #1 

Obi 1 - MIMQ mode and permutation mode 

feedback 


} 







Allocation offset 



Defines the offset in units of slots, from the beginning of the FAST-FEEB ACK uplink bandwidth allocation 
IEEE 802.16 [1], clause 8.4.5.4.9, of the slot in which the SS servicing the CID appearing in the DLC generic 
header, must send a FAST-FEEB ACK feedback message. Range of values to 63. The allocation applies to 
the UL subframe two frames after the frame indicating the fast feedback allocation subheader. 



£75/ 



19 



ETSI TS 102 178 VI .3.1 (2006-02) 



7.4 DLC management messages 



TLVs within DLC Management messages shall be ordered as follows. Parameters for optional features shall occur after 
those listed for support of mandatory features. Features that are defined optional, but are mandated by the implemented 
System Profile, if any, shall be ordered as optional. Both mandatory and optional TLVs shall subsequently be 
sequenced in order of increasing Type value. Parameters with defined default values should be omitted if the desired 
value coincides with the default one. 

When reporting parameters in DLC Management messages, service class names should not be used. 

A set of DLC management messages are defined. These messages shall be carried in the Payload of the DLC PDU. All 
DLC Management messages begin with a Management Message Type field and may contain additional fields. DLC 
management messages on the Basic, Broadcast, and Initial Ranging connections shall neither be fragmented nor packed. 
DLC management messages on the Fragmentable Broadcast connection may be packed and/or fragmented. 
Management messages carried on the Initial Ranging, Broadcast, Fragmentable Broadcast, Basic, and Primary 
Management connections shall have CRC usage enabled. The format of the management message is given in figure 3. 
The encoding of the Management Message Type field is given in table 9. DLC management messages shall not be 
carried on Transport Connections. DLC management messages that have a Type value specified in table 9 as "reserved" 
or those not containing all required parameters or containing erroneously encoded parameters shall be silently 
discarded. 



Management 
Message Type 


Management Message Payload 



Figure 3: DLC Management message format 
Table 9: DLC Management messages 



Type 


Message 


Connection 


Description 





UCD 


Fragmentable 
Broadcast 


Uplink Channel Descriptor 


1 


DCD 


Fragmentable 
Broadcast 


Downlink Channel Descriptor 


2 


DL-MAP 


Broadcast 


Downlink Access Definition 


3 


UL-MAP 


Broadcast 


Uplink Access Definition 


4 


RNG-REQ 


Initial Ranging or 
Basic 


Ranging Request 


5 


RNG-RSP 


Initial Ranging or 
Basic 


Ranging Response 


6 


REG-REQ 


Primary 
IVIanagement 


Registration Request 


7 


REG-RSP 


Primary 
IVIanagement 


Registration Response 


8 


reserved 






9 


PKM-REQ 


Primary 
IVIanagement 


Privacy Key IVIanagement 
Request 


10 


PKM-RSP 


Primary 
IVIanagement 


Privacy Key IVIanagement 
Response 


11 


DSA-REQ 


Primary 
IVIanagement 


Dynamic Service Addition 
Request 


12 


DSA-RSP 


Primary 
IVIanagement 


Dynamic Service Addition 
Response 


13 


DSA-ACK 


Primary 
IVIanagement 


Dynamic Service Addition 
Acknowledge 


14 


DSC REQ 


Primary 
Management 


Dynamic Service Change 
Request 


15 


DSG-RSP 


Primary 
IVIanagement 


Dynamic Service Change 
Response 


16 


DSC-ACK 


Primary 
IVIanagement 


Dynamic Service Change 
Acknowledge 


17 


DSD-REQ 


Primary 
IVIanagement 


Dynamic Service Delete 
Request 
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Type 


Message 


Connection 


Description 


18 


DSD-RSP 


Primary 
Management 


Dynamic Service Delete 
Response 


19 


reserved 






20 


reserved 






21 


MCA-REQ 


Primary 
IVIanagement 


IVIulticast Assignment Request 


22 


MCA-RSP 


Primary 
IVIanagement 


IVIulticast Assignment Response 


23 


DBPC-REQ 


Basic 


Downlink Burst Profile Change 
Request 


24 


DBPC-RSP 


Basic 


Downlink Burst Profile Change 
Response 


25 


RES-CMD 


Basic 


Reset Command 


26 


SBC-REQ 


Basic 


SS Basic Capability Request 


27 


SBC-RSP 


Basic 


SS Basic Capability Response 


28 


CLK-CMP 


Broadcast 


SS network clock comparison 


29 


DREG-CMD 


Basic 


De/Re-register Command 


30 


DSX-RVD 


Primary 
IVIanagement 


DSx Received IVIessage 


31 


TFTP-CPLT 


Primary 
IVIanagement 


Config file TFTP Complete 
Message 


32 


TFTP-RSP 


Primary 
IVIanagement 


Config file TFTP Complete 
Response 



7.4.1 Supplemental DLC management messages 

As shown in table 10, supplemental DLC management messages are defined to facilitate ARQ, channel measurements 
and mesh functionality. 

Table 10: DLC supplemental management messages 



Type 


IVIessage 


Connection 


Description 


33 


ARQ-Feedback 


Basic 


Stand alone ARQ Feedback 


34 


ARQ-Discard 


Basic 


ARQ Discard message 


35 


ARQ-Reset 


Basic 


ARQ Rest message 


36 


REP-REQ 


Basic 


Channel measurement Report 
Request 


37 


REP-RSP 


Basic 


Channel measurement Report 
Response 


38 


FPC 


Broadcast 


Fast Power Control 


39 


MSH-NCFG 


Broadcast 


Mesh Network Configuration 


40 


MSH-NENT 


Basic 


Mesh Network Entry 


41 


MSH-DSCH 


Broadcast 


Mesh Distributed Schedule 


42 


MSH-CSCH 


Broadcast 


Mesh Centralized Schedule 


43 


MSH-CSCF 


Broadcast 


Mesh Centralized Schedule 
Configuration 


44 


AAS-FBCK-REQ 


Basic 


AAS Feedback Request 


45 


AAS-FBCK-RSP 


Basic 


AAS Feedback Response 


46 


AAS Beam Select 


Basic 


AAS Beam Select message 


47 


AAS BEAM REQ 


Basic 


AAS Beam Request message 


48 


AAS BEAM RSP 


Basic 


AAS Beam Response message 


49 


DREG REQ 


Basic 


SS De-registration message 


50 to 255 


Reserved 







During the adaptive antenna system (AAS) portion of the frame, DL-MAP, UL-MAP, DCD, UCD, and CLK-CMP 
messages may be sent using the basic CID. 
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7.4.2 Type 1/3: DL/UL Channel Descriptor (DCD/UCD) message 

A DCD shall be transmitted by the BS at a periodic interval (IEEE 802.16 [1], table 342) to define the characteristics of 
a downlink physical channel. 

Table 1 1 : DCD message format 



Syntax 


Size 


Notes 


DCD Message Format () { 






Management Message Type = 1 


8 bits 




reserved 


8 bits 


Shall be set to zero 


Configuration Change Count 


8 bits 




TLV Encoded information for the overall 
channel 


variable 


TLV specific 


Begin PHY Specific Section { 




See applicable PHY section 


for (/= 1; /<= n; /++) { 




For each downlink burst profile 1 to n 


Downlink Burst Profile 




PHY specific 


1 






} 






} 







A BS shall generate DCDs in the format shown in table 11, including all of the following parameters: 

Configuration Change Count 

• Incremented by one (modulo 256) by the BS whenever any of the values, except the Frame Number, of this 
channel descriptor change. If the value of this count in a subsequent DCD remains the same, the SS can 
quickly decide that the remaining fields have not changed and may be able to disregard the remainder of the 
message. 

For OFDM PHY, the following shall be included in the DCD message: 

• Frame Duration Code. 

• Frame Number. 

The message parameters following the Configuration Change Count shall be encoded in a TLV form. All channel 
encodings shall appear first before the Downlink_Burst_Profile encodings. 

The Downlink_Burst_Profile is a compound TLV encoding that defines, and associates with a particular Downlink 
Interval Usage Code (DIUC), the PHY characteristics that shall be used with that DIUC. Within each 
Downlink_Burst_Profile shall be an unordered list of PHY attributes, encoded as TLV values. Each interval is assigned 
a DIUC by the DL-MAP message. A Downlink_Burst_Profile shall be included for each DIUC to be used in the 
DL-MAP unless the PHY's Downlink_Burst_Profile is explicitly known. 

Downlink_Burst_Profile contents are defined in TS 102 177 [2]. 

TLVs which may be included in the DCD message shall be limited to those listed in table 12. 

Table 12: DL Channel Descriptor TLVs 



Name 


Type 


Length 


Value 


Burst Profile 


1 


variable 


May appear more than once. The length is the number of bytes in 
the overall object, including embedded TLV items. See table 16 


BSEIRP 


2 


2 


Signed in units of 1 dBm 


TTG 


7 


1 


TTG (in PSs). See TS 102 177 [2] 


RTG 


8 


1 


RTG (in PSs). See TS 102 177 [2] 


'^^^IR.max 


9 


2 


Initial Ranging Max. Received Signal Strength at BS 
Signed in units of 1 dBm. Signed integer 










Frame Duration Code 


14 


1 


The duration of the frame. The frame duration code 
values are specified in table 1 1 , in TS 1 02 1 77 [2] 


Frame Number 


15 


3 


The number of the frame containing the DCD 


MAC Version 


18 


1 
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Burst Profile encodings which may be included in the DCD message shall be limited those shown in table 13. 

Table 13: DL burst profile TLVs 



Name 


Type 


Length 


Value 


FEC Code type 


150 


1 


= BPSK (CC) 1/2 11= 64QAM (BTC) 2/3 

1 = QPSK (RS+CC/CC) 1/2 12 = 64QAM (BTC) 5/6 

2 = QPSK (RS+CC/CC) 3/4 13 = QPSK (CTC) 1/2 

3 = 16QAM (RS+CC/CC) 1/2 14 = QPSK (CTC) 2/3 

4 = 16QAM (RS+CC/CC) 3/4 15 = QPSK (CTC) 3/4 

5 = 64QAM (RS+CC/CC) 2/3 16 = 16QAM (CTC) 1/2 

6 = 64QAM (RS+CC/CC) 3/4 17= 16QAM (CTC) 3/4 

7 = QPSK (BTC) 1/2 18 = 64QAM (CTC) 2/3 

8 = QPSK (BTC) 3/4 or 2/3 19 = 64QAM (CTC) 3/4 

9 = 16QAM (BTC) 3/5 20 to 55 = Reserved 

10 = 16QAM(BTC)4/5 


DlUC Mandatory Exit 
Threshold 


151 


1 


to 63. 75 dB 

C/(N+I) at or below which this DlUC can no longer be used and at 

which a change to a more robust DlUC is required, in 0,25 dB 

units 


DlUC Mandatory Entry 
Threshold 


152 


1 


to 63. 75 dB 

The minimum C/(N+I) required to start using this DlUC when 

changing from a more robust DlUC is required, in 0,25 dB units 


TCS_enable 


153 




= TCS disabled 

1 = TCS enabled 

2 to 255 = Reserved 



TLVs which may be included in the UCD message shall be limited to those listed in table 14. 

Table 14: UL Channel Descriptor TLVs 



Name 


Type 


Length 


Value 


Burst Profile 


1 


variable 


May appear more than once. The length is the number of bytes in 
the overall object, including embedded TLV items. See table 16 


Frequency 


5 


4 


Uplink centre frequency (kHz) 


Contention-based 
Reservation Timeout 


2 


1 


Number of UL-MAPs to receive before contention- based 
reservation is attempted again for the same connection 


Subchannelized initial 
ranging 


18 


1 


Indicates whether subchannelized initial ranging is supported 

= Not supported 

1 = Supported 


Subchannelization 
focused contention codes 


151 


1 


Number of contention codes (Cg^) that shall only be used to 

request a subchannelized allocation. Default value 0. Allowed 
values to 8 


Subchannelized 

REQ-Region-Full 

Parameters 


150 


1 


Bits to 2 Number of subchannels used by each transmit 

opportunity 

when REQ Region-Full is allocated in subchannelization 

region, per the following enumeration: 

0: 1 Subchannel 

1 : 2 Subchannels 

2: 4 Subchannels 

3: 8 Subchannels 

4: 16 Subchannels 

5 to 7: Shall not be used 
Bits 3 to 7: Number of QFDM symbols used by each transmit 
opportunity when REQ Region-Full is allocated in 
subchannelization 
region 
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Burst Profile encodings which may be included in the UCD message shall be limited those shown in table 15. 

Table 15: UL burst profile TLVs 



Name 


Type 


Length 


Value 


FEC Code type 


150 


1 


= BPSK (CC) 1/211= 64QAM (BTC) 2/3 

1 = QPSK (RS+CC/CC) 1/2 12 = 64QAM (BTC) 5/6 

2 = QPSK (RS+CC/CC) 3/4 13 = QPSK (CTC) 1/2 

3 = 16QAM (RS+CC/CC) 1/2 14 = QPSK (CTC) 2/3 

4 = 16QAM (RS+CC/CC) 3/4 15 = QPSK (CTC) 3/4 

5 = 64QAM (RS+CC/CC) 2/3 16 = 16QAM (CTC) 1/2 

6 = 64QAM (RS+CC/CC) 3/4 17= 16QAM (CTC) 3/4 

7 = QPSK (BTC) 1/2 18 = 64QAM (CTC) 2/3 

8 = QPSK (BTC) 3/4 or 2/3 19 = 64QAM (CTC) 3/4 

9 = 1 6QAM (BTC) 3/5 20 to 255 = Reserved 

10 = 16QAM(BTC)4/5 


Focused Contention Power Boost 


151 


1 


The power boost in dB of focused contention carriers 
See TS 102 177 [2] for details 



Table 16 defines the format of the Burst_Profile, which is used in both DCD and UCD messages. 

The Burst Profile is encoded with a Type of 1, an 8-bit length, and a 4-bit DIUC/UIUC which is associated with the 
Burst Profile and Thresholds. The DIUC/UIUC value is used in the DL-MAP respectively UL-MAP message to specify 
the Burst Profile to be used for a specific burst. 

Table 16: Burst profile format 



Syntax 


Size 


Notes 


DL/UL Burst Profile format { 






Type = 1 


8 bits 




Length 


8 bits 




Reserved 


4 bits 


Shall be set to 


DIUC/UIUC 


4 bits 




TLV encoded information 


variable 




} 







7.4.3 Type 2: DL-MAP message 

The DL-MAP message defines the access to the downlink information. If the length of the DL-MAP message is a 
non-integral number of bytes, the LEN field in the DLC header is rounded up to the next integral number of bytes. The 
message shall be padded to match this length, but the SS shall disregard the 4 pad bits. 

A BS shall generate DL-MAP messages in the format shown in table 17, including all of the following parameters: 

PHY Synchronization 

• The PHY synchronization field is dependent on the PHY specification used. The encoding of this field is given 
in each PHY specification separately. 

DCD Count 

• Matches the value of the configuration change count of the DCD, which describes the downlink burst profiles 
that apply to this map. 

Base Station ID 

• The Base Station ID is a 48-bit long field identifying the BS. The Base Station ID shall be programmable. The 
most significant 24 bits shall be used as the operator ID. This is a network management hook that can be sent 
with the DCD message for handling edge-of-sector and edge-of-cell situations. 

The encoding of the remaining portions of the DL-MAP message is PHY-specification dependent and may be absent. 
Refer to the appropriate PHY specification. 
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Table 17: DL-MAP message format 



Syntax 


Size 


Notes 


DL-MAP Message format { 






Management Message Type = 2 


8 bits 




PHY Synchronization Field 


variable 




DCD Count 


8 bits 




Base Station ID 


48 bits 




Begin PHY Specific Section { 






if (OFDMA) { 






Number of OFDMA symbols 


8 bits 


Number of OFDMA symbols in the DL 
subframe including all 
AAS/permutation zones 


} 






for (i = 1 ; i <= n; 1++) { 




For each DL-MAP element 1 to n 


DL-MAP IE() 


variable 




1 






} 






if !(byte boundary) { 






Padding Nibble 


4 bits 


Padding to reach byte boundary 


1 






} 







The DL-MAP_IEs in the DL-MAP shall be ordered in the increasing order of the transmission start time of the relevant 
PHY burst. The transmission start time is conveyed by the contents of the DL_MAP_IE in a manner which is PHY 
dependant. 

The logical order in which DLC PDUs are mapped to the PHY layer bursts in the downlink is defined as the order of 
DL-MAP_IEs in the DL-MAP message. 

The following formats shall be used in the DL-MAP and UL-MAP messages. 

7.4.3.1 DL-MAP PHY Synchronization Field 

The PHY Synchronization Field of the DL-MAP message shall have the format shown in table 18. 

Table 18: PHY synchronization field 



Syntax 


Size 


Notes 


Synchronization field { 












1 







Frame number: 

• The modulo 2^^ frame number is increased by one every frame. 
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7.4.3.2 DL-MAP IE format 

DL-MAP Information Elements shall have the format shown in table 19. 

Table 19: DL-MAP information element 



Syntax 


Size 


Notes 


DL-MAP information elementQ { 






CID 


16 bits 




DlUC 


4 bits 




Preamble present 


1 bit 


= not present, 1 = present 
if DlUC == 15 and not Extended 
DlUC = 3, shall be 


Start Time 


1 1 bits 




if (DlUC ==15) 






Extended DlUC dependent IE 


variable 


Report lEQorAAS DL lEQorSTC IE{) 


Padding nibble, if needed 


4 bits 


Completing to nearest byte 


} 







Connection Identifier (CID): 

• Represents the assignment of the IE to a broadcast, multicast, or unicast address. If the broadcast or multicast 
CID is used then it is possible to concatenate unicast DLC PDUs (with different CIDs) into a single DL burst. 
During a broadcast or multicast DL burst it is the responsibility of the BS to ensure that any bursts sent to an 
HFDD SS do not overlap (in time; taking SSTTG and SSRTG into account) any UL allocations for that SS. An 
HFDD SS for which a DL MAP IE and UL MAP IE overlap in time shall use the UL allocation and discard 
DL traffic during the overlapping period. 

Downlink Interval Usage Code (DlUC): 

• A four -bit Downlink Interval Usage Code (DlUC) shall be used to define the burst type associated with that 
time interval. Burst Descriptor shall be included into DCD Message for each DlUC used in the DL-MAP 
except those associated with Gap, End of Map and Extended. The DlUC shall be one of the values defined in 
table 20. 

Preamble present: 

• If set, the indicated burst shall start with the short preamble. 
Start Time: 

• If transmitted in a private map (for compressed private map see IEEE 802.16 [1], clause 8.3.6.6, for reduced 
private map (see IEEE 802.16 [1], clause 8.3.6.7) within an AAS zone, this field indicates the start time, in 
units of symbol duration, relative to the beginning of the subsequent AAS zone (including preamble) where 
the DL-MAP message is transmitted. If transmitted in a compressed private map (see IEEE 802.16 [1], 
clause 8.3.6.6), this field indicates the start time, in units of symbol duration, relative to the beginning of the 
subsequent downlink frame (including preamble). The end of the last allocated burst is indicated by allocating 
a NULL burst (DlUC = 14) with zero duration. The time instants indicated by the Start Time values are the 
transmission times of the first symbol of the burst including preamble (if present). 



Boosting: 



Indication whether the subcarriers for this allocation are power boosted. The field shall be zero when 
describing allocations that use the AMC or PUSC-ASCA permutations in a zone using "Dedicated Pilots". 
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7.4.3.2.1 DlUC allocations 

Table 20 contains the DIUC values used in DL-MAP_IE(). 



Table 20: OFDM DIUC values 



DIUC 


Usage 





STC zone 


1 to 11 


Burst Profiles 


12 


Reserved 


13 


Gap 


14 


End of Map 


15 


Extended DIUC 



7.4.3.2.2 DL-MAP extended IE format 

A DL-MAP IE entry with a DIUC value of 15, indicates that the IE carries special information and conforms to the 
structure shown in table 21. A station shall ignore an extended IE entry with an extended DIUC value for which the 
station has no knowledge. In the case of a known extended DIUC value but with a length field longer than expected, the 
station shall process information up to the known length and ignore the remainder of the IE. 

Table 21 : DL MAP extended IE format 



Syntax 


Size 
(bits) 


Notes 


DL Extended IE() { 






Extended DIUC 


4 


0x00. .OxOF 


Length 


4 


Length in bytes of Unspecified data field 


Unspecified data 


variable 




} 







7.4.3.2.3 Channel measurement DL-MAP IE format 

An extended IE with an extended DIUC value of 0x00 is issued by the BS to request a channel measurement (see 
IEEE 802.16 [1], clause 6.3.2.3.33). The IE includes an 8-bit Channel Nr value as shown in table 22. The IE shall be 
followed by the End of Map IE (DIUC = 14). 

Table 22: Channel measurement Information Element format 



Syntax 


Size 


Notes 


Channel_l\/leasurement_lnformation_ 
ElementO { 






extended DIUC code 


4 bits 


Channel measurement = 0x0 


Length 


4 bits 


Length = 0x1 


Channel Nr 


8 bits 


Channel number 

Shall be set to 0x00 for licensed bands 


} 







7.4.3.2.4 DL-MAP AAS IE format 

Within a frame, the switch from non-AAS to AAS -enabled traffic is marked by using the extended DIUC =15 with the 
AAS_IE() shown in table 23 to indicate that the subsequent allocations, until the start of the first UL-MAP allocation 
using TDD, and until the end of the frame using FDD, shall be for AAS traffic. When used, the CID in the 
DL-MAP_IE() shall be set to the broadcast CID. Subsequent AAS PHY bursts shall all start with the short preamble. 
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Table 23: AAS DL Information Element format 



Syntax 


Size 


Notes 


AAS DL Information element() { 






extended DlUC 


4 bits 


AAS = 0x2 


Length 


4 bits 


Length = 0x0 


} 







7.4.3.2.5 DL-MAP STC IE format 

In the DL-MAP, an STC enabled BS may transmit DIUC = 15 with the STC_IE() shown in table 24 to indicate that the 
subsequent allocations shall be STC encoded. No preceding DL allocations shall be STC encoded and all subsequent 
DL allocations until the end of the frame shall be STC encoded. After this allocation, the BS shall transmit from both its 
antennas until the end of the frame. The first DL allocation following the STC_IE shall contain a preamble. The number 
of OFDM data symbols between two preambles and the number of OFDM data symbols between the last preamble and 
the end of the DL subframe must be even. 

Table 24: STC Information Element format 



Syntax 


Size 


Notes 


STC Information element() { 






extended DIUC code 


4 bits 


STC = 0x4 


Length 


4 bits 


Length = 0x0 


} 







7.4.3.2.6 DL-MAP DUMMY IE format 

A SS shall be able to decode the DL-MAP DUMMY IE for forward compatibility. A BS shall not transmit this IE 
(unless under test). A SS may skip decoding DL bursts scheduled after the Start Time of this IE within the current 
frame. 

Table 25: DL-MAP DUMMY Information Element format 



Syntax 


Size 


Notes 


DUIVIIVIY Information element() { 






extended DIUC 


4 bits 


0x6 to OxF 


Length 


4 bits 


0to15 


Unspecified data 


variable 


The Length field specifies the size of 
this field in bytes 


} 







7.4.3.2.7 DLSUBCHJE format 

In the DL-MAP a DL subchannelization enabled BS (see IEEE 802.16 [1], clause 8.3.5.3) may transmit an extended IE 
with value of 0x05 to indicate that subsequent allocations use DL subchannelization. 

Table 26: DL SUBCH IE format 



Syntax 


Size 


Notes 


DL SUBCH Information element() { 






extended DIUC 


4 bits 


DL SUBCH = 0x5 


Length 


4 bits 


Length = 0x0 


} 
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7.4.4 Type 3: UL-MAP message 



The UL-MAP message allocates access to the uplink channel. The UL-MAP message shall be as shown in table 27. 

Table 27: UL-MAP message format 



Syntax 


Size 


Notes 


UL-MAP Message format { 






Management Message Type = 3 


8 bits 




reserved 


8 bits 


Shall be set to zero 


UCD Count 


8 bits 




Allocation Start Time 


32 bits 




Begin PHY Specific Section { 






if (OFDMA) { 






Number of OFDMA symbols 


8 bits 


Number of OFDMA symbols in the UL 
subframe 


} 






for (i = 1; i <= n; I++) { 




For each UL-MAP element 1 to n 


UL-MAP IE() 


variable 


See corresponding PHY specification 


} 






} 






if !(byte boundary) { 






Padding Nibble 


4 bits 


Padding to reach byte boundary 


} 






} 







The BS shall generate the UL-MAP with the following parameters: 

UCD Count 

• Matches the value of the Configuration Change Count of the UCD which describes the uplink burst profiles 
which apply to this map. 

Allocation Start Time 

• Effective start time of the uplink allocation defined by the UL-MAP (units are PHY-specific, see 10.3). 

Map IBs 

• The contents of a UL-MAP IE is PHY-specification dependent. 

lEs define uplink bandwidth allocations. Each UL-MAP message (except when the PHY layer is OFDMA) shall contain 
at least one IE that marks the end of the last allocated burst. Ordering of lEs carried by the UL-MAP is PHY-specific. 

The CID represents the assignment of the IE to either a unicast, multicast, or broadcast address. When specifically 
addressed to allocate a bandwidth grant, the CID shall be the Basic CID of the SS. A UIUC shall be used to define the 
type of uplink access and the uplink burst profile associated with that access. An Uplink_Burst_Profile shall be included 
in the UCD for each UIUC to be used in the UL-MAP. 

For the OFDMA PHY the UL-MAP message (if such exists) shall always be transmitted on the burst described by the 
first DL_MAP_IE (and following the H-ARQ_MAP_Pointer_IE, if such exists in the OFDMA PHY) of the DL-MAP 
message. If there are multiple PDUs in the burst described by the first DL_MAP_IE, the UL-MAP message shall be the 
first one. 

The logical order in which DLC PDUs are mapped to the PHY layer bursts in the uplink is defined as the order of 
UL-MAP_IEs in the UL-MAP message. 

7.4.4.1 UL-MAP IE format 

The UL-MAP Information Element defines the physical parameters and the start time for UL PHY bursts. The format of 
UL-MAP elements is shown in table 28. 

When subchannelization is active (see clause 4.3.3.3.4), UIUC 3 shall not be used. 
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Table 28: OFDM UL-MAP Information Element format 



Syntax 


Size 


Notes 


UL-MAP information element() { 






CID 


16 bits 




Start Time 


1 1 bits 




Subchannel Index 


5 bits 




UIUC 


4bits 




Duration 


10 bits 




Midamble repetition Interval 


2 bits 


ObOO = Preamble only 

ObOl = IVlidambles after every 8 data symbols 
OblO = IVlidambles after every 16 data symbols 
Obi 1 = IVlidambles after every 32 data symbols 


if (UIUC ==4) 






Focused contention IE{) 


16 bits 




if (UIUC ==13) 






Subchannelized Network Entry IE() 


12 bits 




if (UIUC == 15) 






Extended UIUC dependent IE 


Variable 




} 






Padding nibble 


0/4 bits 


Shall be set to 0x0 


} 







Connection Identifier (CID): 

• Represents the assignment of the IE to a unicast, multicast, or broadcast address. When specifically addressed 
to allocate a bandwidth grant, the CID may be either the Basic CID of the SS or a Traffic CID for one of the 
connections of the SS. 

Uplink Interval Usage Code (UIUC): 

• Shall be used to define the type of uplink access and the burst type associated with that access. A Burst 
Descriptor shall be included into an UCD message for each Uplink Interval Usage Code that is to be used in 
the UL-MAP. The UIUC shall be one of the values defined in table 29. 

Start Time: 

• Indicates the start time, in units of symbol duration, relative to the Allocation Start Time given in the UL-MAP 
message. For non-subchannelized allocations, the duration of the burst is indicated as the difference between 
the start times of current and next map elements. The end of the last allocated burst is indicated by allocating a 
NULL burst (CID = and UIUC = 14). The time instant indicated by the Start Time value is the start of the 
transmission of the preamble. 

Duration: 

• Indicates the duration, in units of OFDM symbols, of the subchannelized allocation. The duration is inclusive 
of the preamble and the midambles contained in the allocation. 

Subchannel Index: 

• See table 1 . 
Midamble repetition interval: 

• Indicates the preamble repetition interval in OFDM symbols. 



£75/ 



30 



ETSI TS 102 178 VI .3.1 (2006-02) 



7.4.4.1.1 UIUC allocations 

Table 29 contains the UIUC values used in the UL-MAP_IE(). 



Table 29: UIUC values 



UIUC 


Usage 





Reserved 


1 


initial ranging 


2 


REQ Region Full 


3 


REQ Region Focused 


4 


Focused Contention IE 


5 to 12 


Burst Profiles 


13 


Gap 


14 


End of IVIap 


15 


Extended UIUC 



7.4.4.1 .2 UL-MAP focused contention IE format 

Table 30 defines the UL-MAP IE for allocation Bandwidth (BW) for a SS that requested bandwidth using Focused 
Contention Reservation Requests. This UL-MAP IE is identified by UIUC = 4 (see table 29). A SS responding to a 
bandwidth allocation using the Focused Contention IE shall start its burst with a short preamble (see clause 5.6) and use 
only the most robust mandatory burst profile in that burst. 

Table 30: Focused contention Information Element format 



Syntax 


Size 


Notes 


Focused Contention IE() { 






Frame number Index 


4 bits 




Transmit Opportunity Index 


3 bits 




Contention Channel Index 


6 bits 




Contention Code Index 


3 bits 




} 







Transmit Opportunity Index: 

• Index number of the Transmit Opportunity that was used in the Bandwidth Request, which this message is 
responding to. Focused Contention Reservation Requests Transmit Opportunities are numbered from 63 to 0, 
starting from the beginning of the frame where the UL-MAP is transmitted. 

Contention Channel Index: 

• Index number of the Contention Channel that was used in the Bandwidth Request, which this message is 
responding to. 

Contention Code Index: 

• Index number of the Contention Code that was used in the Bandwidth Request, which this message is 
responding to. 

7.4.4.1 .3 UL-MAP AAS IE format 

Within a frame, indication of AAS-enabled traffic is marked by using the extended UIUC = 15 with the AAS_IE() 
shown in table 31 to indicate that the subsequent allocations be for AAS traffic. When used, the CID in the 
UL-MAP_IE() shall be set to the broadcast CID. Subsequent AAS PHY bursts shall all start with the short preamble. 
Stations not supporting the AAS functionality may treat the AAS_IE as a start of gap. The AAS_IE() shall not be used 
in AAS private map messages. 
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Table 31 : AAS UL IE format 



Syntax 


Size 


Notes 


AAS Information element() { 






extended UIUC code 


4 bits 


AAS = 0x02 


Length 


4 bits 


Length = 0x0 


} 







7.4.4.1 .4 UL-MAP subchannelization IE format 

Within a frame, the BS may allocate a portion of the UL allocations to subchannelized traffic. 

Table 32: Subchannelization IE format 



Syntax 


Size 


Notes 


Subchannelization Information elementQ { 






extended UIUC code 


4 bits 


Subchannelization = 0x03 


Length 


4 bits 


Length = 0x2 


Length of Allocations 


16 bits 




} 







Length of allocations 

• The number of bytes, following the subchannelization_IE, that are used to define subchannelized allocations. 
A SS not capable of using subchannelization may skip interpreting this number of bytes in the UL-MAP. 

7.4.4.1 .5 UL-MAP DUMMY IE format 

An SS shall be able to decode the UL-MAP DUMMY IE for forward compatibility. A BS shall not transmit this IE 
(unless under test). 

Table 33: UL-MAP DUMMY Information Element format 



Syntax 


Size 


Notes 


DUMMY Information element() { 






extended UIUC 


4 bits 


0x4 to OxF 


Length 


4 bits 


Oto 15 


Unspecified data 


variable 


The Length field specifies the size of 
this field in bytes 


} 







7.4.4.1.6 Fast_Ranging_IE 

A Fast_Ranging_IE may be placed in the UL-MAP message by a BS to provide a non-contention based initial-ranging 
opportunity. The Fast_Ranging_IE shall be placed in the extend UIUC (extension code = 0x03) within a UL-MAP IE. 
The Fast_Ranging_IE shall be assigned to the initial ranging CID=OxOOOO. 
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Table 34: OFDM Fast_Ranging_IE format 



Syntax 


Size 


Notes 


Fast Ranging Information element() { 






extended UIUC 


4 bits 


0x3 


Length 


4 bits 


0x8 


IVIAC address 


48 bits 


SS's IVIAC address as provided on 
the RNG-REQ message on initial 
entry 


UIUC 


4 bits 


UIUC ^ 1 5. A code used to define 
the type of uplink access and the 
first type associated with that access 


Duration 


12 bits 


The length, in units of OFDIVI 
symbols, of the allocation. The start 
time of the first allocation shall be 
the Allocation Start Time given in the 
UL-MAP message 


} 







BS may assign subchannel indices other than OblOOOO, only to SS which entered the network using the subchannelized 
network entry (see IEEE 802.16 [1], clause 8.3.6.3.3). 

7.4.4.1 .7 UL-MAP Fast Tracking IE 

The UL-MAP Fast tracking information element in an UL-MAP entry is used to provide fast power, time and frequency 
indications/corrections to SS s that have transmitted in the previous frame. 

The extended UIUC=15 shall be used for this IE with sub-code 0x04. 

The CID used in the Information Element shall be a broadcast CID. 

Table 35: UL fast tracking IE format 



Syntax 


Size 


Notes 


Fast Tracking Information element() { 






extended UIUC 


4 bits 


0x4 


Length 


4 bits 


Variable 


for (1 = 1; ikn; i++) { 






Power correction 


2 bits 


Power correction indication: 
ObOO: no change 
0b01:+2dB 
Ob10:-1 dB 
Obi 1 : -2 dB 


Frequency correction 


4 bits 


The correction is 0,1 % of the carrier 
spacing multiplied by the 4-bit 
number interpreted as a signed 
integer (i.e. Obi 000: -8; ObOOOO: 0; 
0b0111:7) 


Time correction 


2 bits 


The correction is floor(2/Fs) 

multiplied by 

ObOO: 

Ob01: 1 

Ob10:-1 

Ob1 1 : Not used 


} 






} 







The UL Fast tracking IE is optional in the UL-MAP. When this IE is sent, it provides an indication about corrections 
that should be applied by SS s that have transmitted in the previous UL frame. Each indication byte shall correspond to 
one unicast allocation-IE that has indicated an UL burst allocation in the previous UL-MAP. The order of the indication 
bytes shall be the same as the order of the unicast allocation-IE in the UL-MAP. 

The response time for corrections following receipt of this IE shall be equal to Ranging Response Processing Time as 
defined in IEEE 802.16 [1], clause 10.1. 
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7.4.4.2 Compressed private maps 

Compressed private maps are defined in IEEE P802.16e [4], clause 8.3.6.6. 

7.4.4.2.1 Compressed private DL-MAP 

Compressed private DL-MAP is defined in IEEE P802.16e [4], clause 8.3.6.6.1. 

7.4.4.2.2 Compressed private UL-MAP 

Compressed private UL-MAP is defined in IEEE P802.16e [4], clause 8.3.6.6.2. 

7.4.4.3 Reduced private maps 

Reduced private maps are defined in IEEE P802.16e [4], clause 8.3.6.7. 

7.4.4.3.1 Reduced private DL-MAP 

Reduced private DL-MAP is defined in IEEE P802.16e [4], clause 8.3.6.7.1. 

7.4.4.3.2 Reduced private UL-MAP 

Reduced private UL-MAP is defined in IEEE P802.16e [4], clause 8.3.6.7.2. 

7.4.5 Type 4/5: RaNGing REQuest/ReSPonse (RNG-REQ/RSP) message 

The RNG-REQ message is as defined in IEEE 802.16 [1], clause 6.3.2.3.5. 
The RNG-RSP message is as defined in IEEE 802.16 [1], clause 6.3.2.3.6. 
In addition to the TLVs listed in IEEE 802.16 [1], the following TLVs are defined. 

7.4.5.1 AAS Support 

To indicate whether it can receive broadcast transmissions, an AAS-enabled SS may include the following TLV in 
RNG-REQ messages: 

• AAS Broadcast Capabihty. 

Table 36: Supplemental RNG-REQ TLVs 



Name 


Type 


Length 


Value 


AAS broadcast capability 


4 


1 


= SS can receive broadcast messages 

1 = SS cannot receive broadcast messages 



To indicate whether an SS, which set the AAS Broadcast Capability, may issue contention-based BVv' requests, an 
AAS-enabled BS may use the following TLV in RNG-RSP messages: 

• AAS Broadcast Permission. 

The following RNG-RSP TLVs may be sent by the BS to indicate the reception of an undecodable initial ranging 
(RNG-REQ) attempt or to indicate the reception of a subchannelized initial ranging attempt. 

• Frame Number: 

Initial Ranging Opportunity Number. 
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Table 37: Supplemental RNG-RSP TLVs 



Name 


Type 


Length 


Value 


Timing Adjust 


1 


4 


Tx timing offset adjustment (signed 32-bit). The time by 
which to advance SS transmission so that frames arrive at 
the expected time instance at the BS 
See TS 102 177 [2], clause 14 for unit definition 


AAS broadcast permission 


11 


1 


= SS may issue in contention-based BW requests 

1 = SS may not issue in contention-based BW requests 


Frame Number 


12 


3 


Frame number in which the undecodable initial ranging or 
subchannelized initial ranging attempt was detected by the 
BS. Usage is mutually exclusive with SS MAC Address. 
The opportunity within the frame is assumed to be 1 (the 
first) if the Initial Ranging Opportunity Number field is not 
supplied 


Initial Ranging Opportunity Number 


13 


1 


Initial Ranging opportunity (1 to 255) in which the 
undecodable initial ranging or subchannelized initial 
ranging attempt was detected by the BS. Usage is 
mutually exclusive with SS IVIAC Address 



7.4.5.2 Power management support 



Table 38: TLVs for power management 



Name 


Type (1 byte) 


Length 


Value (Variable Length) 


Power level Adjust 


2 


1 


Tx Power offset adjustment (signed 8-bit, 0,25 dB units). 
Specifies the relative change in transmission power level that the 
SS is to make in order that transmissions arrive at the BS at the 
desired power 

When subchannelization is employed, The subscriber shall 
interpret the power offset adjustment as a required change to the 
transmitted power density 



7.4.6 Type 6: REGistration-REQuest (REG-REQ) message 

In PMP mode during Registration, the SS shall generate REG-REQ messages including the following parameter in 
addition to those specified in IEEE 802.16 [1], clause 6.3.2.3.7: 

• MAC Version. 

• Maximum transmit power. 

• Amplifier backoffs. 

• Current transmitted power. 

The transmitted power parameters are defined in table 39. 

Table 39: Transmitted power parameters 



Name 


Type 
(1 byte) 


Length 


Value 
(variable length) 


Scope 


Maximum Tx power 


5.23 


1 


Achievable transmit power (peak) signed, 
0,5 dB increments 




Amplifier backoffs 


5.24 


3 


Byte 0: QPSK 

Byte 1 : 1 6QAM 

Byte 2: 640AM (report as 0x0 if not 

supported). Backoff values in 0,25 dB 

increments 




Current Tx power 


5.25 


1 


Current transmit power (peak) signed. 
0,5 dB increments 
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In Mesh mode during Registration, the Candidate Node shall generate REG-REQ messages including the following 
parameters: 

• SS MAC Address. 

• MAC Version: 

The MAC Version implemented in the Candidate Node. 

• HMAC Tuple: 

Message digest calculated using HMAC_KEY_U. 
Both in PMP and Mesh mode, the REG-REQ may in addition contain the following parameters: 

• IP Version. 

• SS Capabilities Encodings. 

• Vendor ID Encoding. 

7.4.7 Type 7: REGistration-ReSPonse (REG-RSP) message 

In Mesh mode during Registration, the Registration Node shall generate REG-RSP messages including the following 
parameters: 

• Node ID. 

• MAC Version: 

MAC Version used in the network. 

• HMAC Tuple: 

Message digest calculated using HMAC_KEY_D. 

In Mesh mode, the REG-RSP is as defined in IEEE 802.16 [1], clause 6.3.2.3.8 and may in addition contain the 
following parameters: 

• IP Version. 

• SS Capabilities Encodings: 

Capabilities returned in the REG-RSP shall not be set to require greater capability of the Node than is 
reported in the REG-REQ. 

• Vendor Specific Extensions. 

7.4.8 Type 9/1 0: Privacy Key Management (PKM-REQ/RSP) messages 

PKM employs two DLC message types: PKM Request (PKM-REQ) and PKM Response (PKM-RSP), as described in 
table 40. 

Table 40: PKM DLC messages 



Type Value 


Message 


Description 


9 


PKM-REQ 


Privacy Key Management Request (SS to BS) 


10 


PKM-RSP 


Privacy Key Management Response (BS to SS) 



These DLC management message types distinguish between PKM requests (SS-to-BS) and PKM responses 
(BS-to-SS). Each message encapsulates one PKM message in the Management Message Payload. 
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PKM protocol messages transmitted from the SS to the BS shall use the form shown in table 41. They are transmitted 
on the SSs Primary Management Connection. 

Table 41 : PKM request message format 



Syntax 


Size 


Notes 


PKM-REQ Message Format () { 






Management Message Type = 9 


8 bits 




Code 


8 bits 




PKM Identifier 


8 bits 




TLV Encoded Attributes 


variable 


TLV specific 


} 







Table 42: PKM response message format 



Syntax 


Size 


Notes 


PKM-RSP Message Format () { 






Management Message Type = 10 


8 bits 




Code 


8 bits 




PKM Identifier 


8 bits 




TLV Encoded Attributes 


variable 


TLV specific 


} 







Code 

• The Code is one byte and identifies the type of PKM packet. When a packet is received with an invalid Code, 
it shall be silently discarded. The code values are defined in table 43. 

PKM Identifier 

• The Identifier field is one byte. An SS uses the identifier to match a BS response to the SS's requests. 

The SS shall increment (modulo 256) the Identifier field whenever it issues a new PKM message. A "new" message is 
an Authorization Request or Key Request that is not a retransmission being sent in response to a Timeout event. For 
retransmissions, the Identifier field shall remain unchanged. 

The Identifier field in Authentication Information messages, which are informative and do not effect any response 
messaging, shall be set to zero. The Identifier field in a BS's PKM-RSP message shall match the Identifier field of the 
PKM-REQ message the BS is responding to. The Identifier field in TEK Invalid messages, which are not sent in 
response to PKM-REQs, shall be set to zero. The Identifier field in unsolicited Authorization Invalid messages shall be 
set to zero. 

On reception of a PKM-RSP message, the SS associates the message with a particular state machine (the Authorization 
state machine in the case of Authorization Replies, Authorization Rejects, and Authorization Invalids; a particular TEK 
state machine in the case of Key Replies, Key Rejects, and TEK Invalids). 

An SS shall keep track of the identifier of its latest, pending Authorization Request. The SS shall discard Authorization 
Reply and Authorization Reject messages with Identifier fields not matching that of the pending Authorization Request. 

An SS shall keep track of the identifiers of its latest, pending Key Request for each SA. The SS shall discard Key Reply 
and Key Reject messages with Identifier fields not matching those of the pending Key Request messages. 



Attributes 



PKM attributes carry the specific authentication, authorization, and key management data exchanged between 
client and server. Each PKM packet type has its own set of required and optional attributes. Unless explicitly 
stated, there are no requirements on the ordering of attributes within a PKM message. The end of the list of 
attributes is indicated by the LEN field of the DLC PDU header. 
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Table 43: PKM message codes 



Code 


PKM message type 


Name 


0-2 


reserved 




3 


SAAdd 


PKM-RSP 


4 


Auth Request 


PKM-REQ 


5 


Auth Reply 


PKM-RSP 


6 


Auth Reject 


PKM-RSP 


7 


Key Request 


PKM-REQ 


8 


Key Reply 


PKM-RSP 


9 


Key Reject 


PKM-RSP 


10 


Auth Invalid 


PKM-RSP 


11 


TEK Invalid 


PKM-RSP 


12 


Auth Info 


PKM-REQ 


13-255 


reserved 





Formats for each of the PKM messages are described in IEEE 802.16 [1], clause 6.3.2.3.9. 

In Mesh mode, the Authorization reply attributes and the Key request attributes listed in tables 44 and 45 shall be used. 
The HMAC-Digest's authentication key is derived from the Authorization key or the Operator Shared Secret. 

Table 44: Authorization Reply attributes 



Attribute 


Contents 


Operator Shared Secret 


Key known to all nodes 


Key-Sequence-Number 


Operator Shared Secret's sequence number 


Key-Lifetime 


Operator Shared Secret's active lifetime 



Table 45: Key Request attributes 



Attribute 


Contents 


SS Certificate 


X.5G9 Certificate of the node 


SAID 


SA Identifier 


HMAC-Digest 


HMAC using HMAC KEY S 



7.4.9 Type 1 1 : Dynamic Service Addition-Request (DSA-REQ) 

A DSA-REQ message is defined as in IEEE 802.16 [1], clause 6.3.2.310. 

7.4.1 Type 1 2: Dynamic Service Addition-ReSPonse (DSA-RSP) 

A DSA-RSP message is defined as in IEEE 802.16 [1], clause 6.3.2.311. 

No TLVs besides Error Encodings and HMAC Tuples shall be reported back in DSA-RSP. 

7.4.1 1 Type 1 3: Dynamic Service Addition-ACKnowledgement (DSA-ACK) 

A DSA-ACK message is defined as in IEEE 802.16 [1], clause 6.3.2.312. 

No TLVs besides HMAC Tuples shall be reported back in DSA-ACK messages. 

7.4.1 2 Type 1 4: Dynamic Service Cinange-REQuest (DSC-REQ) 

A DSC-REQ message is defined as in IEEE 802.16 [1], clause 6.3.2.313. 

DSC-REQ messages shall not contain Request/Transmission Policy, Fixed vs. Variable Length SDU Indicator, SDU 
Size, ATM Switching, or Convergence Sublayer Specification TLVs. 
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7.4.1 3 Type 1 5: Dynamic Service Cinange-ReSPonse (DSC-RSP) 

A DSC-RSP message is defined as in IEEE 802.16 [1], clause 6.3.2.3.14. 

No TLVs besides Error Encodings and HMAC Tuples shall be reported back in DSC-RSP. 

7.4.1 4 Type 1 6: Dynamic Service CInange-ACKnowledge (DSC-ACK) 

A DSC-ACK message is defined as in IEEE 802.16 [1], clause 6.3.2.15. 

7.4.1 5 Type 1 7: Dynamic Service Delete-REQuest (DSD-REQ) 

A DSD-REQ message is defined as in IEEE 802.16 [1], clause 6.3.2.3.16. 

7.4.1 6 Type 1 8: Dynamic Service Delete-ReSPonse (DSD-RSP) 

A DSD-RSP message is defined as in IEEE 802.16 [1], clause 6.3.2.3.17. 

7.4.1 7 Type 21 : Multicast polling Assignment REQuest (MCA-REQ) 

A MCA-REQ message is defined as in IEEE 802.16 [1], clause 6.3.2.3.18. 

7.4.1 8 Type 22: Multicast polling Assignment ReSPonse (MCA-RSP) 

A MCA-RSP message is defined as in IEEE 802.16 [1], clause 6.3.2.3.19. 

7.4.1 9 Type 23: Downlink Burst Profile Change-REQuest (DBPC-REQ) 

A DBPC-REQ message is defined as in IEEE 802.16 [1], clause 6.3.2.3.20. 

7.4.20 Type 24: Downlink Bust Profile Change-ReSPonse (DBPC-RSP) 

A DBPC-RSP message is defined as in IEEE 802.16 [1], clause 6.3.2.3.21. 

7.4.21 Type 25: RESet CoMmanD (RES-CMD) 

A RES-CMD message is defined as in IEEE 802.16 [1], clause 6.3.2.3.22. 

7.4.22 Type 26/27: SS Basic Capability-REQuest/ReSPonse 
(SBC-REQ/RSP) 

The following Physical Parameter encodings shall be available for use with SBC-REQ and SBC-RSP. The Physical 
Parameters listed in IEEE 802.16 [1], clause 11.8.3 shall not be used. 

7.4.22.1 OFDM demodulator 

This field indicates the different demodulator options supported by a SS for DL reception. A bit value of indicates 
"not supported" while 1 indicates "supported". 



Type 


Length 


Value 


Scope 


5.12.28 


1 


bit#0 64QAM 


SBC-REQ 






bit#1 Reserved. Set to 


SBC-RSP 






bit#2 CTC 








bit#3 SIC 








bit#4 AAS 








bit#5 to 7 Reserved. Set to 





£75/ 



39 



ETSI TS 102 178 VI .3.1 (2006-02) 



7.4.22.2 OFDM modulator 

This field indicates the different modulator options supported by a SS for UL transmission. A bit value of indicates 
"not supported" while 1 indicates "supported". 



Type 


Length 


Value 


Scope 


5.12.29 


1 


bit#0 64QAM 


SBC-REQ 






bit#1 Reserved. Set to 


SBC-RSP 






bit#2 CTC 








bit#3 Subchannelization 








bit#4 Focused contention BW request 








bit#5-7 Reserved. Set to 





7.4.22.3 Subscriber transition gaps 

This field indicates the transition speed SSTTG and SSRTG for TDD and H-FDD SSs. 



Type 


Length 


Value 


Scope 


5.12.30 


2 


Bit #0 to 7: SSTTG (ms) 

Bit#8to15:SSRTG(|Js) 

Allowed values: 

OFDM: TDDand H-FDD: to 100 |js 

OFDMA: TDD to 50 |js; H-FDD 1 to 100 |JS 


SBC-REQ 
SBC-RSP 



7.4.22.4 Bandwidth allocation support 

This field indicates the different BW allocation options supported by a SS. A bit value of indicates "not supported" 
while 1 indicates "supported". 



Type 


Length 


Value 


Scope 


5.15 


1 


bit #0: Reserved. Set to 
bit #1 = 0: Half-Duplex (FDD only) 
bit#1 =1: Full-Duplex (FDD only) 
bit #2-7: reserved; shall be set to zero 


SBC-REQ 
SBC-RSP 



7.4.23 Type 33: ARQ Feedback message 

A system supporting ARQ shall be able to receive and process the ARQ Feedback message. 

The ARQ Feedback message, as shown in table 46, can be used to signal any combination of different ARQ ACKs 
(cumulative, selective, selective with cumulative). The message shall be sent on the appropriate basic management 
connection. 

Table 46: ARQ Feedback message format 



Syntax 


Size 


Notes 


ARQ Feedback Message Format() { 






Management Message Type = 33 


8 bits 




ARQ Feedback Payload 


variable 


See table 76 


} 







ARQ Feedback information shall be either sent using this ARQ Feedback message or by packing the 
ARQ_Feedback_Payload as described in clause 5.1.2. 
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7.4.24 Type 34: ARQ_Discard message 

This message is applicable to ARQ-enabled connections only. 

The transmitter sends this message when it wants to skip a certain number of ARQ blocks. The ARQ Discard message 
shown in table 47 shall be sent as a DLC management message on the basic management connection of the appropriate 
direction. 

Table 47: ARQ Discard message format 



Syntax 


Size 


Notes 


ARQ Discard Message Format{) { 






Management Message Type = 34 


8 bits 




Connection ID 


16 bits 


Applicable CID 


Reserved 


5 bits 




Block Sequence Number 


1 1 bits 


Sequence number of the last block in the transmission 
window to be discarded 


} 







7.4.25 Type 35: ARQ_Reset message 

This message is applicable to ARQ-enabled connections only. 



The transmitter or the receiver may send this message. The message is used in a three-part dialog to reset the parent 
connection's ARQ transmitter and receiver state machines. The ARQ Reset message, as shown in table 48, shall be sent 
as a DLC management message on the basic management connection of the appropriate direction. 

Table 48: ARQ_Reset message format 



Syntax 


Size 


Notes 


ARQ Reset Message Format() { 






Management Message Type = 36 


8 bits 




Connection ID 


16 bits 


Applicable CID 


Type 


2 bits 


00 = Original Message from Initiator 

01 = Acknowledgement from Responder 

10 = Confirmation from Initiator 

1 1 = Reserved 


Reserved 


6 bits 




} 







7.4.26 Type 36/37: Report-Request (REP-REQ/RSP) message 

The Report Request message, shown in table 49, shall be used by the BS to request RSSI and CINR channel 
measurement reports. 

Table 49: REP-REQ message format 



Syntax 


Size 


Notes 


Report Request Message Format() { 






Management Message Type = 36 


8 bits 




Report Request TLV 


variable 




} 







The Report Request TLV shall have the format shown in table 50. 

Table 50: Report Request TLV 



Name 


Type 


Length 


Value 


Report Request 


1 


Variable 
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The Report Request shall consist of the parameters in table 5 1 . 

Table 51 : Report Request parameters 



Name 


Type 


Length 


Value 


Report Type 


1.1 


1 


Bit #0 Reserved, shall be set to 

bit#1 1 = Include CINR report 

bit #2 1 = Include RSSI report 

bit #3 to 6 Ogyg in multiples of 1/32 (range [1/32, 16/32]) 

bit #7 1 = Report background noise 



When bit#7 is set, bit#l shall be and bit#2 shall be 1. The response shall contain the RSSI as measured during the 
period indicated by the last DL-MAP Report IE. 

The Report Response message, shown in table 52 shall be used by the SS to respond with the channel measurements 
requested in the last received Report Request. 

Table 52: REP-RSP message format 



Syntax 


Size 


Notes 


Report Response Message Format() { 






Management Message Type = 37 


8 bits 




Current Tx Power 


8 bits 


Current transmit power (peak) in 0,5 dB increments 


Report Response TLV 


variable 


Compound TLV that shall contain the measurement 
Report in accordance with the Report Request 


} 







The Report Response TLV shall have the format shown in table 53. 

Table 53: Report Response TLV 



Name 


Type 


Length 


Value 


Report Response 


1 


Variable 





The Report Response shall consist of the parameters in table 54. 

Table 54: Report Response parameters 



Name 


Type 


Length 


Value 


CINR Report 


1.3 


2 


Insert if REP-REQ bit#1 = 1 

1 byte CINR mean 

1 byte CINR standard deviation 


RSSI Report 


1.4 


2 


Insert if REP-REQ bit#2 = 1 

1 byte RSSI mean 

1 byte RSSI standard deviation 



7.4.27 Type 38: Fast Power Control (FPC) message 

Power control shall be provisioned by the use of periodic ranging. In addition, the BS may adjust the power levels of 
multiple subscribers simultaneously with the Fast Power Control (FPC) message. SSs shall apply the indicated change 
within the "SS DL management message processing time". PFC shall be sent on the broadcast CID. 
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Table 55: Fast Power Control message format 



Syntax 


Size 


Notes 


Fast Power Control message format () { 






Management message type = 38 


8 bits 




Number of stations 


8 bits 




for (i = 0;i<Number of stations;i++) { 






Basic CID 


16 bits 




Power Adjust 


8 bits 




} 






} 







Number of stations: 

• Number of CID and Power Adjust tuples contained in this message. 
Basic CID: 

• Basic connection identifier associated with the SS. 
Power Adjust: 

• Signed integer, which expresses the change in power level (in multiples of 0,25 dB) that the SS shall apply to 
its current transmission power. 

7.4.28 Type 39: MeSH Network ConFiGuration (MSH-NCFG) message 

MeSH Network ConFiGuration (MSH-NCFG) messages provide a basic level of communication between nodes in 
different nearby networks whether from the same or different equipment vendors or wireless operators. 

The MSH-NCFG packets shall be used to convey information about network status and configuration such as: 

• synchronization across multiple mesh networks; 

• communication of channels in use across multiple networks; and 

• support of network entry for new or mobile nodes. 

All the nodes shall generate MSH-NCFGs in the format shown in table 56. 
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Table 56: MSH-NCFG message format 



Syntax 


Size 


Notes 


Report Response IVIessage Format() { 






IVIanagement IVIessage Type = 39 


8 bits 




NumNbrEntries 


5 bits 




NumBSEntries 


2 bits 


Number of mesh BS neighbours to be reported on 


Embedded Packet Flag 


1 bit 


1 = present, = not present 


Xmt Power 


4 bits 


In 2 dBm steps, starting from 0x0 = 8 dBm 


Xmt Antenna 


3 bits 


Antenna used for transmission of this message 


NetEntry IVIAC Address Flag 


1 bit 


1 = present, = not present 


Network Base Channel Logical Number 


4 bits 




Reserved 


4 bits 




NetConfig Counter 


4 bits 


Incremented by 1 for every transmitted MSH-NCFG 


TimeStamp 

Frame_Number 

Network Ctrl Slot Number In frame 

Number of hops to master sync, node 


12 bits 
4 bits 
8 bits 




NetConfig Schedule Info 
Next Xmt Mx 
Xmt Holdoff Exponent 


3 bits 
5 bits 




If (NetEntry MAC Address Flag) 
NetEntry MAC Address 


48 bits 




for (i = 0; i<NumBSEntries;++i) { 






BS Node ID 


1 6 bits 


Node ID of the mesh BS reported on 


Number of hops to BS 


3 bits 


Number of hops to this mesh BS 


Xmt energy/bit to BS 


5 bits 




} 






for (i = 0; i<NumNbrEntries;++i) { 






Nbr Node ID 


16 bits 


Node ID of the neighbour node reported on 


MSH-NCFG Nbr Physical IE() 


16 bits 


See table 57 


if (Logical Link Info Present) 
MSH-NCFG Nbr Logical IE() 


16 bits 


Indicated in preceding MSH-Nbr_Physlcal_IE() 
See table 58 


} 






If (Embedded Packet Flag) 

MSH-NCFG embedded data() 


variable 




} 







NumNbrEntrie s : 

• Number of neighbours reported on in the message. The number of neighbours reported on may be a fraction of 
the whole set of neighbours known to this node. A node can report on subsequent subsets of neighbours in its 
subsequent MSH-NCFG transmissions. 

The following procedure is used to select the list neighbours of which only the Physical IE is reported: 

i) All neighbour entries with the "Reported Flag" set to TRUE are excluded as defined below. 

ii) The remaining neighbour entries are ordered by the Next Xmt Time and those with the Next Xmt Time 
the furthest in the future are reported in this MSH-NCFG packet. (In general, learning of nodes with Next 
Xmt Times furthest into the future is more valuable than learning of nodes with Next Xmt Times 
approaching soon, since the neighbours will have more time to use this ineligibility information before it 
is stale.) 

The "Reported Flag" for all neighbours in either of the above neighbour lists is set to TRUE upon transmission 
of this MSH-NCFG packet. It is set to FALSE as described in clause 9.5.1. 

Network Base Channel Logical Number: 

• The logical number of the base channel being used in this node's network, which is the logical number of the 
physical channel which shall be used to broadcast schedule control information. The possible physical channel 
numbers is mapped to logical channels in the Network Descriptor (see clause 7.4.28.3.1). 
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Netconfig counter: 

• Counter of MSH-NCFG packets transmitted by this node. Used by neighbours to detect missed transmissions. 
Incremented by 1 for every MSH-NCFG transmission by this node. 

Frame number: 

• A modulo 2^^ number, which shall be increased by one for every frame. 
Network Control Slot Number in frame: 

• See TS 102 177 [2] for details. 

Number of hops to master sync, node: 

This counter is used to determine superiority between nodes when synchronizing the network. Nodes can 
be assigned as master time keepers, which are synchronized externally (for example using GPS). Nodes 
shall synchronize to the node with the lowest number of hops to master sync, node, or if counts are the 
same, to the node with the lower Node ID. 

Netconfig Schedule Info 

Xmt Holdoff Exponent: 

• The Xmt Holdoff Time is the number of MSH-NCFG transmit opportunities after Next Xmt Time (there are 
MSH-CTRL-LEN -1 opportunities per network control subframe), that this node is not eligible not transmit 
MSH-NCFG packets. 

Xmt Holdoff Time = 2^^'^' «°^'^°^^ Exponent+4) ( j^ 

Next Xmt Mx: 

• Next Xmt Time is the next MSH-NCFG eligibility interval for this neighbour and computed as the range: 
2Xmt Holdoff Exponent ^ ^^^^ ^mt Mx < Next Xmt Time < 2^'"' "°''^°*'*' ^^P™™' x (Next Xmt Mx + 1). (2) 

For example, if Next Xmt Mx = 3 and Xmt Holdoff Exponent = 4, then the node shall be considered eligible 
for its next MSH-NCFG transmission between 49 and 64 (due to the granularity) transmission opportunities 
away and ineligible before that time. 

If the Next Xmt Mx field is set to OxlF (all ones), then the neighbour should be considered to be eligible to 
transmit from the time indicated by this value and every MSH-NCFG opportunity thereafter (i.e. treat Xmt 
HoldoffTime = 0). 

NetEntry MAC Address: 

• Indicates presence or sponsorship of new node. See MSH-NENT message in clause 7.4.29 and network entry 
in clause 9.6. 

Xmt energy/bit factor: 

• Indication of energy/bit needed to reach mesh BS through this node. Xmt energy/bit is computed as: 

£■; = min [Pj^ I Rj^ j+eA mW//s (3) 



where: Nis the set of neighbours reporting this mesh BS: 

P^x is the transmission power in mW from node ; to nodey 

Ri^ j is the datarate in Mbps from node / to node j. 
E j is the Xmt energy/bit reported by neighbour y. 
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The reported Xmt energy/bit factor is computed as: 

Xmter.ergy/bitfactor = XmtenergyW^^^^^^^^^^^^^^^^_^_^^ 



(4) 



where XmtEnergyUnitExponent is a 4-bit field reported in the most recent Network Descriptor. 

7.4.28.1 Nbr Physical Information Element 

Table 57: MSH-NCFG_Nbr_Physical_lnformation_Element 



Syntax 


Size 


Notes 


MSH-NCFG Nbr Physical IE() { 






Logical Link Info Present 


1 bit 


Indicates whether IVISH-NCFG Nbr Logical IE follows 


Logical Link requested 


1 bit 


1 = Yes, = No 


Logical Link Accepted 


1 bit 


1 = Yes, = No 


Hops to Nbr 


1 bit 


= 1 hop (direct neighbour), 1 = 2 hops 


Propagation delay 


4 bits 


Estimated propagation delay in |js 


Nbr NetConfig Schedule Info 
Nbr Next Xmt Mx 
Nbr Xmt Holdoff Exponent 


5 bits 
3 bits 




} 







7.4.28.2 Nbr Logical Information Element 



Table 58: MSH-NCFG_Nbr_Logical_lnformation_Element 



Syntax 


Size 


Notes 


MSH-NCFG Nbr Logical IE() { 






Rev Link Quality 


3 bits 




Nbr Burst Profile 


4 bits 




Excess Traffic Demand 


1 bit 


1 = Yes, = No 


Nbr Xmt Power 


4 bits 


(see table 56) 


Nbr Xmt Antenna 


3 bits 


(see table 56) 


Short Preamble Flag 


1 bit 


= do not use, 1 = use requested/confirmed 


} 







Rev Link Quahty: 

• Measure of the receive Hnk reliability, indicating the reliability of MSH-NCFG size packets using the 
indicated burst profile. The estimated reliability is indicated as: 

reliability = lOOx (l - lO'^'^'^^ ^ink Quality+1)/4'J ^^ (5) 

Nbr burst profile: 

• Indicated the burst profile the indicated node should use when sending data bursts to the reporting node. 
Excess traffic demand: 

• May be used to indicate to the neighbour that the current schedule is insufficient to transfer pending traffic. 
Short Preamble flag: 

• A node may optionally set this bit to notify the neighbour to use the short preamble for transmissions in the 
data portion of the frame. Capability to transmit the short preamble is mandatory. Capability to receive it is 
optional. 
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Table 59: MSH-NCFG Embedded Data 



Syntax 


Size 


Notes 


MSH-NCFG Embedded Data() { 






Extended embedded_data 


1 bit 


Indicates whether this embedded IE is followed by 
another one 
= No, 1 = Yes 


Reserved 


3 bits 




Embedded_Data_IE_Type 


4 bits 


0x0 = Reserved 

0x1 = Network Descriptor 

0x2 = Network Entry Open 

0x3 = Network Entry Reject 

0x4 = Network Entry Ack (Length shall be set to 0) 

0x5 = Neighbour Link Establishment Protocol 


Length 


8 bits 


Length of the MSH-NCFG_Embedded_Data_IE in 
bytes, exclusive this header 


MSH-NCFG Embedded data IE() 


variable 


Embedded Data IE Type dependent 


1 







7.4.28.3.1 Network Descriptor Embedded Data Information Element 

The Network Descriptor Embedded_data_IE shall contain the shown in table 60. 

Table 60: Network Descriptor Information Element 



Syntax 


Size 


Notes 


MSH-NCFG Embedded Data IE() { 






Frame Length Code 


4 bits 


4 Isb of Frame Duration Code. See TS 102 177 [2] 


MSH-CTRL-LEN 


4 bits 


Control subframe length 


MSH-DSCH-NUM 


4 bits 


Number of DSCH opportunities in schedule control 
subframe 


MSH-CSCH-DATA-FRACTION 


4 bits 




Scheduling Frames 


4 bits 


Defines how many frames have a schedule control 
subframe between two frames with network control 
subframes in multiples of 4 frames 

= frames; 

1 = 4 frames, etc. 


Num_Burst_Profiles 


4 bits 




Operator ID 


16 bits 




XmtEnergyUnitsExponent 


4 bits 




Num Channels 


4 bits 


Number of logical channels 


MinCSForwardingDelay 


7 bits 


Number of OFDM symbols delay inserted between 
receiving and forwarding control packets 


ExtendedNeighborhoodType 


1 bit 


= 2-hop neighbourhood 

1 = 3-hop neighbourhood 


If (Num Channels) 

MSH-NCFG NetDesc Channel IE() 


variable 




for (i = 0;i < BurstProfileCount;i-n-) { 






FEC Code Type 


8 bits 


See table 14 


Mandatory Exit Threshold 


8 bits 


Mandatory Entry Threshold 


8 bits 


1 






} 
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MSH-CSCH-DATA-FRACTION: 

• Maximum percentage (value x 6,67) of minislots in the data-subframe allocated to centralized scheduling. The 
number of minislots is rounded to the nearest whole number of minislots and allocated starting from the 
beginning of the data subframe. The remainder of the data subframe, as well as any minislots not occupied by 
the current centralized schedule, may be used for distributed scheduling. 

ExtendedNeighborhoodType: 

• If value 0, then only nodes with Hops to Neighbour = are reported, if value 1, then also nodes with Hops to 
Neighbour = 1 are reported. 

MinCSForwardingDelay: 

• The minimum delay in OFDM symbols that shall be inserted between the end of reception and the start of 
transmission of a Centralized Scheduling message (i.e. MSH-CSCH and MSH-CSCF) by any node. 

Table 61 : MSH-NCFG NetDesc Channel Information Element 



Syntax 


Size 


Notes 


MSH-NCFG NetDesc Channel IE() { 






for (i = 0;i< Channels; ++i) { 




PHY dependent. Index "1" corresponds to logical 
channel 


Physical channel centre frequency 


24 bits 


Positive integer in kHz 


Physical channel width 


8 bits 


Positive integer in 100 kHz 


} 






Channel Re-use 


3 bits 


IVIinimum number of hops of separation between links, 
before a channel can be re-used by the centralized 
scheduling algorithm. Range is 1 hop to 7 hops, for 
no re-use 


Reserved 


5 bits 




} 







7.4.28.3.2 Network Entry Open Embedded Data Information Element 

The Network Entry Open, which is used to respond to MSH-NENT request messages, shall contain the form as shown 
in table 62. 

Table 62: Network Entry Open Information Element 



Syntax 


Size 


Notes 


MSH-NCFG Embedded Data IE() { 






Minislot Start 


8 bits 


Schedule start for upper layer network entry 


Minislot Range 


8 bits 


Schedule range for upper layer network entry 


Frame number 


12 bits 


Frame number this schedule becomes valid 


Channel 


4 bits 


Logical channel for new node to Xmt in above Minislot 
Range 


Schedule validity 


12 bits 


Validity of Schedule in frames 


Channel 


4 bits 


Logical Rev channel for new node 


Estimated Propagation Delay 


4 bits 


In |js 


Reserved 


4 bits 




} 
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7.4.28.3.3 Network Entry Reject Embedded Data Information Element 

The Network Entry Reject, which is used to reject MSH-NENT request messages, shall contain the form as shown in 
table 63. 

Table 63: Network Entry Reject Information Element 



Syntax 


Size 


Notes 


MSH-NCFG Embedded Data IE() { 






Rejection Code 


8 bits 


0x0: Operator Authentication Value Invalid 
0x1 : Excess Propagation delay 
0x2: Select new sponsor 


Rejection Reason 


160 bits 


ASCII string 


} 







7.4.28.3.4 Neighbour Link Establishment Embedded Data Information Element 

The Neighbour Link Establishment, which is used to establish links between nodes as described in clause 9.2, shall 
contain the form as shown in table 64. 

Table 64: Link Establishment Information Element 



Syntax 


Size 


Notes 


MSH-NCFG Embedded Data IE() { 






Action Code 


2 bits 


0x0 = Challenge 

0x1 = Challenge Response 

0x2 = Accept 

0x3 = Reject 


Reserved 


6 bits 




if (Action Code == 0x0 or 0x1) 
Nbr Authentication Value 


32 bits 




if (Action Code == 0x1 or 0x2) 
Link ID 


8 bits 


Transmitting node's Link ID for this link 


} 







Nbr Authentication Value: 

Nbr Authentication Value = HMACJAuthorization Key I Frame Number I Node ID self I Node ID other} (6) 
where the Authorization Key is a secret key (obtained from Operator). 

7.4.29 Type 40: MeSH-Network ENTry (MSH-NENT) message 

MeSH Network ENTry (MSH-NENT) messages provide the means for a new node to gain synchronization and initial 
network entry into a mesh network. When a MSH-NENT message, shown in table 65, is sent, the mesh Subheader is set 
to 0x0000 until the node has been assigned a node ID. In the Mesh CID, The Network ID is set the sponsor's network 
code or to 0x0000 if not known and the Link ID is set to OxFF (Broadcast). 
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Table 65: MSH-NENT message format 



Syntax 


Size 


Notes 


MSH-NENT Message Format() { 






MAC Management Message Type = 40 


8 bits 




MSH-NENT_Type 


3 bits 


0x0 = Reserved 
0x1 = NetEntryAck 
0x2 = NetEntryRequest 
0x3 = NetEntryClose 


if (MSH-NENT Type ==0x1) 

MSH-NENT_Type being Ack-ed 

else 

Xmt counter for this MSH-NENT Type 


3 bits 
3 bits 




Reserved 


2 bits 




Sponsor Node ID 


16 bits 


ID of the node sought to assist the requesting node in 
entering the network 


Xmt Power 


4 bits 


See table 56 


Xmt Antenna 


3 bits 


See table 56 


Reserved 


1 bit 




if (MSH-NENT Type == 0x2) 






MAC Address 


48 bits 


MAC Address of the new node sending the request 


OpConflnfo 


64 bits 


Operator Configuration Information (obtained from 
Operator) 


Operator Authentication Value 


32 bits 




Node Serial Number 


32 bits 




} 






1 







Operator Authentication Value: 

Operator Authentication Value = HMACJMAC Address I Node Serial Number I Authorization Key} (7) 
where the Authorization Key is a secret key (obtained from Operator) 

7.4.30 Type 41 : MeSH-Distributed SCHeduling (MSH-DSCH) message 

MeSH Distributed SCHeduling (MSH-DSCH) messages shall be transmitted in mesh mode when using distributed 
scheduling. In coordinated distributed scheduling, all the nodes shall transmit a MSH-DSCH, shown in table 66 at a 
regular interval to inform all the neighbours of the schedule of the transmitting station. This transmission time is 
determined by the same algorithm used for MSH-NCFG messages. In both coordinated and uncoordinated scheduling, 
MSH-DSCH messages shall be used to convey resource requests and grants to the neighbours. Further the MSH-DSCH 
messages shall be used to convey information about free resources that the neighbours can issue grants in. This message 
shall not be fragmented. 
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Table 66: MSH-DSCH message format 



Syntax 


Size 


Notes 


MSH-DSCH Message Format() { 






DLC Management Message Type = 41 


8 bits 




Coordination Flag 


1 bit 


= Coordinated 

1 = Uncoordinated 


Grant/Request Flag 


1 bit 


= Request message 

1 = Grant message (also used as Grant confirmation) 


MSH-DSCH Sequence Counter 


6 bits 




Num Requests 


4 bits 


Number of Request lEs in the message 


Num_Availabilities 


4 bits 


Number of Availability lEs in the message. The 
Availability lEs are used to indicate free minislot 
ranges that neighbours could issue Grants in 


Num Grants 


6 bits 


Number of Grant lEs in this message 


Reserved 


2 bits 




if (Coordination Flag == 0x0) 
MSH-DSCH Scheduling IE() 


variable 




for (i = 0;i< Num Requests; -i-i-i) 
MSH-DSCH Request IE() 


16 bits 




for (i = 0;i< Num Availabilities; -i-i-i) 
MSH-DSCH Availability IE() 


32 bits 




for (i = 0;i< Num Grants; -i-i-i) 
MSH-DSCH Grant IE() 


40 bits 




} 







Co-ordination Flag: 



• Coordinated MSH-DSCH transmissions take place in the control subframe. Uncoordinated MSH-DSCH 
transmissions take place in the data subframe. Both the cases require a threeway handshake (Request, Grant 
and Grant confirmation) to establish a valid schedule. Uncoordinated scheduling may only take place in 
minislots which cause no interference with the coordinated schedule. 

Grant/Request Flag: 

• The Request Type indicates that a new Request is made of one or more other nodes. The No. Requests shall be 
non-zero in this case. The message may also contain Availabilities and Grants. 

The Grant Type indicates that one or more Grants are given or confirmed. The Num_Grants shall be non-zero 
in this case. The message may also contain Availabilities and Requests. Requests in this type of message 
indicate pending demand to the indicated node(s), but do not solicit a Grant from this node. 
This flag is always set to for coordinated distributed scheduling. 

MSH-DSCH Sequence Counter: 

• Sequentially increased counter for solicit messages in uncoordinated scheduling (used as multiple solicits 
might be outstanding). In coordinated scheduling, it allows nodes to detect missed scheduling messages. 
Independent counters are used for the coordinated and uncoordinated messages. 

7.4.30.1 MSH-DSCH Scheduling Information Element 

The Coordinated distributed scheduling information carried in the MSH-DSCH message, shown in table 67, shall be 
used to distribute information needed to determine transmission timing of the MSH-DSCH messages with coordinated 
distributed scheduling. Each node shall report the two related parameters both of its own and all its neighbours. 
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Table 67: MSH-DSCH Scheduling Information Element 



Syntax 


Size 


Notes 


MSH-DSCH Scheduling IE() { 






DSCH Schedule Info 
Next Xmt IVIx 
Xmt Holdoff Exponent 


3 bits 
5 bits 




Num_SchedEntries 


8 bits 


Number of Neighbour MSH-DSCH Scheduling Entries 
in the message 


for (i = 0; i< Num SchedEntries; -i-i-i) { 






Nbr Node ID 


16 bits 


The Node ID of the neighbour being reported on 


Nbr DSCH Schedule Info 
Nbr Next Xmt Mx 
Nbr Xmt Holdoff Exponent 


3 bits 
5 bits 


Advertise as reported by neighbour 


} 







DSCH Schedule Info. 
Xmt Holdoff Exponent: 

• The Xmt Holdoff Time is the number of MSH-DSCH transmit opportunities after Next Xmt Time (there are 
MSH-CTRL-LEN -1 opportunities per network control subframe, that this node is not eligible not transmit 
MSH-DSCH packets. 

Xmt Holdoff Time = 2^^"^' "°''^°f*' Exponent+4) (g^ 

Next Xmt Mx: 

• Next Xmt Time is the next MSH-DSCH eligibility interval for this neighbour and computed as the range: 

jXmt Holdoff Exponent ^ ^^^^ ^mt Mx < Next Xmt Time < 2^™' ""''^"^^ Exponent ^ ^ j^^^^ ^mt Mx + 1) (9) 

EXAMPLE: If Next Xmt Mx = 3 and Xmt Holdoff Exponent = 4, then the node shall be considered eligible for 
its next MSH-DSCH transmission between 49 and 64 (due to the granularity) transmission 
opportunities away and ineligible before that time. 

If the Next Xmt Mx field is set to OxlF (all ones), then the neighbour should be considered to be 
eligible to transmit from the time indicated by this value and every MSH-DSCH opportunity 
thereafter (i.e. treat Xmt Holdoff Time = 0). 

7.4.30.2 MSH-DSCH Scheduling Information Element 

The Requests carried in the MSH-DSCH message shall convey resource requests on per link basis, as shown in table 68. 

Table 68: MSH-DSCH Request Information Element 



Syntax 


Size 


Notes 


MSH-DSCH Request lEQ { 






Link ID 


8 bits 


The ID assigned by the transmitting node to the link to 
this neighbour that this request involves 


Demand Level 


8 bits 


Demand in minislots (assuming the current burst 
profile) 


Persistence 


3 bits 


Persistency field for demands. Number of frames over 

which the demand exists 

= cancel reservation, 1 = single frame, 

2 = 2 frames, 3 = 4 frames, 

4 = 8 frames, 5 = 32 frames, 

6= 128 frames, 

7 = Good until cancelled or reduced 


Reserved 


1 bit 




} 
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7.4.30.3 MSH-DSCH Availability Information Element 

The Availabilities carried in the MSH-DSCH message shall be used to indicate free minislot ranges that neighbours 
could issue Grants in. Each Availability shall be indicated using the IE shown in table 69. 

Table 69: MSH-DSCH Availability Information Element 



Syntax 


Size 


Notes 


MSH-DSCH Availability IE() { 






Start Frame Number 


8 bits 


Indicates lowest 8 bits of frame number in which the availability 
starts 


IVIinislot start 


8 bits 


The start position of the availability within the frame 


IVIinislot Range 


7 bits 


The number of consecutive available minislots 


Direction 


2 bits 


= Minislot range is unavailable 

1 = Available for transmission in this minislot range 

2 = Available for reception in this minislot range 

3 = Available for either transmission or reception 


Persistence 


3 bits 


Persistency field for Availabilities. Number of frames over which 

the Availability is valid 

= cancel availability, 1 = single frame, 

2 = 2 frames, 3 = 4 frames, 

4 = 8 frames, 5 = 32 frames, 

6= 128 frames, 

7 = Good until cancelled or reduced 


Channel 


4 bits 


Logical channel number on which the availability exists 


} 







7.4.30.4 MSH-DSCH Grant Information Element 

The Grants carried in the MSH-DSCH message shall convey information, as shown in table 70, about a granted minislot 
range selected from the range reported as available. Grants shall be used both to grant and confirm a grant. 

Table 70: MSH-DSCH Grant Information Element 



Syntax 


Size 


Notes 


MSH-DSCH Grant IE{) { 






Link ID 




The ID assigned by the transmitting node to the neighbour that 
this Grant involves 


Start Frame Number 


8 bits 


Indicates lowest 8 bits of frame number in which the Grant starts 


Minislot start 


8 bits 


The start position of the Grant within the frame 


Minislot Range 


7 bits 


The number of consecutive minislots granted 


Direction 


2 bits 


= From requester to grantor 

1 = To requester from granter 


Persistence 


3 bits 


Persistency field for Grants. Number of frames over which the 

Availability is valid 

= cancel reservation, 1 = single frame, 

2 = 2 frames, 3 = 4 frames, 

4 = 8 frames, 5 = 32 frames, 

6= 128 frames, 

7 = Good until cancelled or reduced 


Channel 


4 bits 


Logical channel number on which the availability exists 


} 







7.4.31 Type 42: MeSH-Centralized SCHeduling (MSH-CSCH) message 

A MeSH Centralized SCHeduling (MSH-CSCH) message shall be created by a mesh BS when using centralized 
scheduling. The BS shall broadcast the MSH-CSCH message, as shown in table 71, to all its neighbours, and all the 
nodes with hop count lower than HOPRANGE_THRESHOLD shall forward the MSH-CSCH message to their 
neighbours that have a higher hop count. In all these cases, the Grant/Request Flag = 0. HOPRANGE_THRESHOLD is 
a configuration value that need only be known to the mesh BS, as it can be derived by the other nodes from the 
MSH-CSCF message. 
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Nodes can use MSH-CSCH messages to request bandwidth from the mesh BS setting the Grant/Request Flag = 1. Each 
node reports the individual traffic demand requests of each "child" node in its subtree from the BS. The nodes in the 
subtree are those in the current scheduling tree to and from them mesh BS, known to all nodes in the network, and 
ordered by node ID. 

Table 71 : MSH-CSCH message format 



Syntax 


Size 


Notes 


MSH-CSCH Message Format() { 






DLC Management Message Type = 42 


8 bits 




MSH-CSCF Sequence Number 


3 bits 


Indicates the configuration, which shall be used to 
interpret this packet 


Grant/Request Flag 


1 bit 


= Grant message (transmitted up the tree) 

1 = Request message (transmitted down the tree) 


Frame Schedule Flag 


1 bit 


If this flag is set, the allocation of flows shall occur 
over two frames, rather than one 


Configuration Flag 


1 bit 




Reserved 


2 bits 




Num FlowEntries 


8 bits 




for (i = 0;i< Num FlowEntries; -i-i-i) { 






UL Flow 


4 bits 




If (Grant/Request Flag == 0) 






DL Flow 


4 bits 




} 






FlowScale Exponent 


4 bits 




Padding Nibble 


4 bits 


Pad till byte boundary 


If (Grant/Request Flag == 1) { 






Num LinkUpdates 


4 bits 




for (i = 0;i< Num LinkUpdates; -i-i-i) { 






Node Index self 


8 bits 


Index self in MSH-CSCF list 


Node Index parent 


8 bits 


Index parent in MSH-CSCF list 


UL Burst Profile 


4 bits 


Burst Profile for transmitting up the tree 


DL Burst Profile 


4 bits 


Burst Profile for transmitting down the tree 


} 






} else { 




Sponsor Node Request 


Sponsor Node 


8 bits 


index in MSH-CSCF list 


DL Burst Profile 


4 bits 




UL Burst Profile 


4 bits 




} 






} 







Sponsor Node Request: 



Three parameters (Sponsor Node, and Burst Profiles) shall be set to 0, except by nodes which wish to reserve 
an allocation for the "upper DLC initialization" as specified in clause 9.6.4. A node may only set these values 
if all its children report these values as 0. The Mesh BS shall in response provide a grant to Node Index 0x00, 
which shall be reserved for this purpose. 



Configuration Flag: 



Indicates which centralized scheduling control message type (CSCH or CSCF) will be transmitted next by the 
Mesh BS. This bit may be set to aid the nodes in computing the validity of the schedule indicated in the current 

message (see clause 9.8.2). 



FlowScale Exponent: 



Determines scale of the granted bandwidth. Its value typically depends on the number of nodes in the network, 

the achievable PHY bitrate, the traffic demand and the provided service. 

For the DL, this gives the absolute values of flow granted, so the total minislot range allowed for centralized 

scheduling need not be used if not needed, with the remainder set aside for distributed scheduling. 

For the UL, the lowest exponent possible is used at each hop, with quantization of forwarded requests rounded 

up (e.g. avoids reducing any requests to zero). 
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NumFlowEntries: 



Number of 8-bit assignment fields followed, ordered according to appearance in MSH-CSCF. This number 
shall match the number of entries in the most recent MSH-CSCF message. 



UL_Flow. 
DL Flow: 



Base of the granted/requested bandwidth as bits/s for DL respectively UL traffic of the node in the BS's 
scheduling tree. The flow only indicates traffic that initiates or terminates in the node itself (i.e. forwarded 
traffic is not included), except for traffic forwarded from/to nodes not part of the MSH-CSCF tree. The actual 
granted/requested bandwidth shall be calculated as: 



BWuL =UL_Flowx(2P*°*^'=^''=E''P°"'="'+'4) ^-^^/^ 
BWdl =DL_Flowx(2P'°*^'=^''=E''P™™'+i4) ^-^^/^ 



(10) 



The assignments in the list are ordered according to the order in the MSH-CSCF message. 

Num_LinkUpdates : 

• Link updates are inserted by the mesh BS if the number of link tree changes does not warrant a MSH-CSCF 
broadcast. The mesh BS shall repeat the link update in every MSH-CSCH either until the update becomes 
invalid, or until the change is reflected in a MSH-CSCF message. 

7.4.32 Type 43: MeSH-Centralized Scheduling ConFiguration (MSH-CSCF) 
message 

A MeSH Centralized Scheduling ConFiguration (MSH-CSCF) message shall be broadcast in mesh mode when using 
centralized scheduling. The mesh BS shall broadcast the MSH-CSCF message, as shown in table 72, to all its 
neighbours, and all nodes shall forward (rebroadcast) the message according to its index number specified in the 

message. 

Table 72: MSH-CSCF message format 



Syntax 


Size 


Notes 


MSH-CSCF Message Format() { 






DLC Management Message Type = 43 


8 bits 




MSH-CSCF Sequence Number 


4 bits 


The BS shall increment this number by one for every 
MSH-CSCF message it transmits 


Num_Channels 


4 bits 


Number of channels available for centralized 
scheduling 


for (i = 0;i< Num_Channels; ++i) { 
Logical Channel Number 


4 bits 


The logical index of the Physical channel, as reported 
in MSH-NCFG Network Descriptor 


Padding nibble 


0/4 bits 


Pad till byte boundary 


Num Nodes 


8 bits 




for (i = 0;i< Num Nodes; ++i) { 






Node ID 


16 bits 


Unique node identifier assigned to node 


Num Children 


8 bits 




for (j = 0;j< Num Children; ++j) { 






Child Index 


8 bits 


Index child in Node list 


UL Burst Profile 


4 bits 


Burst Profile for transmitting up the tree from this child 


DL Burst Profile 


4 bits 


Burst Profile for transmitting down the tree to this child 


1 






1 






} 
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7.4.33 Type 44/45: AAS-FeedBaCK REQuest/ReSPonse (AAS-FBCK 
REQ/RSP) message 

AAS Feedback messages as shown in tables 73 and 74 are used to obtain channel state information as described in 
clause 7.4. 

Table 73: AAS-FeedBaCK REQuest (AAS-FBCK-REQ) message format 



Syntax 


Size 


Notes 


AAS Feedback Request Message Format() { 






Management Message Type = 44 


8 bits 




Frame Number 


24 bits 




Number of Frames 


7 bits 




Measurement Data Type 


1 bit 


= measure on DL preamble only 

1 = measure on DL data (for this SS) only 


Feedback Request Counter 


6 bits 




Frequency Measurement 
Subcarrier Resolution 


2 bits 


ObOO = 4 
Ob01 = 8 
0b10 = 16 
Ob1 1 = 32 


} 







Frame Number: 

• The Frame Number in which the measurement shall be started. 
Number of Frames: 

• The number of frames over which the measurement shall be averaged. 
Frequency Measurement Subcarrier Resolution: 

• Indicates the frequency measurement points to report on. Measurement points shall be on the frequencies 
corresponding to the negative subcarrier offset indices -Nuj,gjj/2 plus n times the indicated subcarrier resolution 
and corresponding to the positive subcarrier offset indices Nuj,gy2 minus n times the indicated subcarrier 
resolution where n a positive integer. See TS 102 177 [2], clause 4.2. 

Feedback Request Counter: 

• Increased by one every time an AAS-FBCK-REQ is sent to the SS. Individual counters shall be maintained for 
each SS. 

Table 74: AAS-FeedBaCK-ReSPonse (AAS-FBCK-RSP) message format 



Syntax 


Size 


Notes 


AAS Feedback Response Message Format() { 






Management Message Type = 45 


8 bits 




Reserved 


2 bits 


Set to ObOO 


Feedback Request Counter 


6 bits 




for (i = 0; i<Number of Frequencies; i++) { 




According to Frequency Measurement 
Subcarrier Resolution 


Re(Frequency[i]) 


8 bits 




lm(Frequency[i]) 


8 bits 




1 






} 







Feedback Request Counter: 

• Counter from the AAS-FBCK-REQ messages to which this is the response. 
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Frequency: 

• The Real (Re) and Imaginary (Im) part of the measured amphtude on the frequency measurement point (low to 
high frequency) in signed integer fixed point format ([±][4 bits]. [4 bits]. 

7.4.34 Type 46 to 255: DUMMY message 

A SS shall be capable of decoding the DUMMY message shown in table 75. A BS shall not transmit this message 
unless in test mode. A SS shall not transmit this message. 

Table 75: DUMMY message format 



Syntax 


Size 


Notes 


DUMMY Message Format() { 






Management Message Type = 46. ..255 


8 bits 




Length 


8 bits 




Unspecified data 


Length x 8 bits 




} 







Length: 

• The Length in bytes of the following "Unspecified data". 



8 Automatic Repeat reQuest (ARQ) 

The ARQ mechanism is an optional part of the DLC layer and can be enabled on a per-connection basis. The 
per-connection ARQ and associated parameters shall be specified and negotiated during connection creation or change. 
A connection cannot have a mixture of ARQ and non-ARQ traffic. Similar to other properties of the DLC protocol the 
scope of a specific instance of ARQ is limited to one unidirectional connection. 

For ARQ-enabled connections, enabling of fragmentation is optional. When fragmentation is enabled, the transmitter 
may partition each SDU into fragments for separate transmission based on the value of the ARQ_BLOCK_SIZE 
parameter. 

Connections are set and defined dynamically through the DS A/DSC class of messages. CRC-32 shall be used for error 
detection of PDUs for all ARQ-enabled connections. All ARQ parameters (see clause 8.2) shall be set and all ARQ 
variables (see clause 8.3) shall be reset (set to 0) on connection setup. 

ARQ feedback information can be sent as a standalone DLC management message (see table 46) on the appropriate 
basic management connection, or can be piggybacked on an existing connection using the ARQ Feedback Payload 
(see table 76). ARQ Feedback message shall not be fragmented. 

8.1 Packing for ARQ-enabled connections 

The use of packing subheaders for ARQ-enabled connections is similar to that for non-ARQ connections, except that 
ARQ-enabled connections use Packing or Fragmentation Subheaders of Extended Type, so bit#3 in the general DLC 
header's Type field shall be set (see table 2). DLC PDUs transmitted at ARQ-enabled connections must have either 
Fragmentation Subheader or Packing Subheaders to provide each payload with block sequence numbers information. If 
packing is turned on for a connection, the DLC may pack multiple DLC SDUs or fragments thereof into a single DLC 
PDU. The transmitting side has full discretion whether or not to pack a group of DLC SDUs and/or fragments in a 
single DLC PDU. The packing of variable -length DLC SDUs for the ARQ-enabled connections is similar to that of 
non-ARQ connections, when fragmentation is enabled. The BSN of the Packing Subheader shall be used by the ARQ 
protocol to identify and retransmit lost fragments. 

8.1 .1 Interaction of packing with fragmentation 

For ARQ-enabled connections, when the general DLC header's Type (see table 2) indicates packing is used (i.e. when 
bit#5 is set), fragmentation information for each individual DLC SDU or DLC SDU fragment is contained in the 
associated Packing Subheader. 
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When the Type field indicates that packing is not used, fragmentation information for the DLC PDU's single payload 
(DLC SDU or DLC SDU fragment) is contained in the Fragmentation Subheader. Each of the packed DLC SDU or 
DLC SDU fragments or ARQ feedback payload shall have its own packing subheader and some of them may be 
transmissions while others are re-transmissions. 

8.1 .2 Packing ARQ Feedback Information Elements 

An ARQ Feedback Payload (see table 76) consists of one or more ARQ Feedback Information Elements (see table 77). 
The ARQ Feedback Payload may be sent on an ARQ or non-ARQ connection. However, policies based on 
implementation and/or QoS constraints may restrict the use of certain connections for transporting the ARQ Feedback 
Payload. The ARQ Feedback Payload is treated like any other payload (SDU or fragments) from the packing 
perspective, except that only one ARQ Feedback Payload shall be present within a single DLC PDU. 

Table 76: ARQ Feedback Payload 



Syntax 


Size 


Notes 


ARQ Feedback Payload { 






do 






ARQ Feedback lE(last) 


variable 


Insert as many as desired, until last == TRUE 


until (last) 






1 







The presence of an ACK Feedback Payload in a DLC PDU is indicated by the value of bit #4 of the Type field in the 
generic DLC header. When present, the first packed payload shall be the ARQ Feedback Payload. The Packing 
Subheader preceding the ARQ Feedback Payload indicates the total length of the payload including the Packing 
Subheader and all ARQ Feedback Information Elements within the payload. The FSN/BSN field of the Packing 
Subheader shall be ignored for the ARQ Feedback Payload and the EC bits shall be set to ObOO. 

Table 77: ARQ Feedback Information Element 



Syntax 


Size 


Notes 


ARQ feedback IE (last) { 


variable 




CID 


16 bits 


The ID of the connection being referenced 


Last 


1 bit 


= More ARQ feedback IE in the list 

1 = Last ARQ feedback IE in the list 


ACK Type 


2 bit 


0x0 = Selective ACK entry, 

0x1 = Cumulative ACK entry, 

0x2 = Cumulative with Selective ACK entry, 

0x3 = Cumulative ACK with Block Sequence Ack 

entry 


BSN 


1 1 bits 




Num_ACK_IVIaps 


2 bits 


If ACK Type == 01 , the field is reserved and set to 00 
Otherwise the field indicates the number of ACK maps: 
0x0 = 1 , 
0x1 = 2, 
0x2 = 3, 
0x3 = 4 


if (ACK Type! =01) { 






for (i = 0; i< NUIVl ACK Maps; ++i) { 






if (ACK Type! = 03) { 






Selective ACK Map 


16 bits 




} 






else { 






Sequence Format 


1 bit 


Number of block sequences associated with descriptor 
0: 2 block sequences 
1 : 3 block sequences 


if (Sequence Format = 0) { 






Sequence ACK Map 


2 bits 




Sequence 1 Length 


6 bits 




Sequence 2 Length 


6 bits 




Reserved 


1 bit 




} 
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Syntax 


Size 


Notes 


else { 






Sequence ACK Map 


3 bits 




Sequence 1 Length 


4 bits 




Sequence 2 Length 


4 bits 




Sequence 3 Length 


4 bits 




} 






} 






1 






} 






} 







BSN: 



If (ACK Type == 0x0): BSN value corresponds to the most significant bit of the first 16-bit ARQ ACK map. 

If (ACK Type == 0x1): BSN value indicates that its corresponding block and all blocks with lesser values 
within the transmission window have been successfully received. 

If (ACK Type == 0x2): Combines the functionality of types 0x0 and 0x1. 

If (ACK Type == 0x3): Combines the functionality of type 0x1 with the ability to acknowledge reception of 
ARQ blocks in terms of block sequences. A block sequence is defined as a set of ARQ blocks with 
consecutive BSN values. With this option, members of block sequences are identified and associated with the 
same reception status indication. 



Selective ACK Map: 



Each bit set to one indicates the corresponding ARQ block has been received without errors. The bit 
corresponding to the BSN value in the IE, is the most significant bit of the first map entry. The bits for 
succeeding block numbers are assigned left-to-right (MSB to LSB) within the map entry. If the ACK Type 
is 0x2, then the most significant bit of the first map entry shall be set to one and the IE shall be interpreted as a 
cumulative ACK for the BSN value in the IE. The rest of the bitmap shall be interpreted similar to ACK 
Type 0x0. 



Sequence ACK Map: 



Each bit set to one indicates the corresponding block sequence has been received without error. The MSB of 
the field corresponds to the first sequence length field in the descriptor. The bits for succeeding length fields 
are assigned left-to-right within the map entry. Since the block sequence described by the first descriptor of the 
first map entry of the IE corresponds to the sequence of blocks immediately after the Cumulative ACK, the 
ACK map bit for this sequence shall be zero indicating this sequence has not yet been received. 



Sequence Length: 



This value indicates the number of blocks that are members of the associated sequence. The BSN of the first 
block of the block sequence described by the first descriptor of the first IE map entry is the value of the 
Cumulative ACK plus one. The BSN of the first block of each block sequence is determined by adding the 
BSN of the first block of the previous block sequence to the length of that sequence. Within a map entry. 
Sequence Map/Length ordering follows the rule specified in the definition of Sequence ACK Map. Across 
map entries, ordering moves from the first map entry (i=0) to the last map entry (i=Number of ACK Maps). 



8.2 ARQ parameters 



ARQ_BLOCK_SIZE: 

• ARQ_BLOCK_SIZE is the basic retransmission unit and it should be negotiated during connection setup. The 
concept of blocks is described in clause 5.4. 

ARQ_BSN_MODULUS: 

• ARQ_BSN_MODULUS is equal to the number of unique BSN values, i.e. 2 048. 
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ARQ_WINDOW_SIZE: 



• ARQ_WINDOW_SIZE is the maximum number of the unacknowledged ARQ blocks at any given time, 
which shall be less than or equal to half of ARQ_BSN_MODULUS. An ARQ block is unacknowledged if it 
has been transmitted but no acknowledgement has been received. 

ARQ_BLOCK_LIFETIME: 

• ARQ_BLOCK_LIFETIME is the maximum time interval beyond which a transmitter shall discard 
unacknowledged ARQ blocks. 

ARQ_RETRY_TIMEOUT: 

• ARQ_RETRY_TIMEOUT is the minimum time interval a transmitter shall wait before retransmitting an 
unacknowledged ARQ block. 

ARQ_SYNC_LOSS_TIMEOUT: 

• ARQ_SYNC_LOSS_TIMEOUT is the length of a time interval from last transmitted/received SDU, in which 
at least one DLC PDU was transmitted/received with no change in the position of ARQ Tx/Rx window, after 
this time interval passed, ARQ synchronization shall be considered lost. 

ARQ_RX_PURGE_TIMEOUT: 

• ARQ_RX_PURGE_TIMEOUT is the time interval the receiver shall wait after successful reception of a block 
that does not result in advancement of ARQ_RX_WINDOW_START, before advancing 
ARQ_RX_WINDOW_START. 

8.3 ARQ variables 

ARQ_TX_WINDOW_START: 

• All ESN up to (ARQ_TX_WINDOW_START - 1) have been acknowledged. 
ARQ_TX_NEXT_BSN: 

• BSN of the next block to send. This value shall be between ARQ_TX_WINDOW_START and 
(ARQ_TX_WINDOW_START + ARQ_WINDOW_SIZE). 

ARQ_RX_WINDOW_START: 

• All BSN up to (ARQ_RX_WINDOW_START - 1) have been correctly received. 
ARQ_RX_HIGHEST_BSN: 



• 



BSN of the highest block received, plus one. This value shall be between ARQ_RX_WINDOW_START and 
(ARQ_RX_WINDOW_START + ARQ_WINDOW_SIZE). 



8.4 ARQ operation 
8.4.1 ARQ block usage 

The clause describes the use of blocks for ARQ. A DLC SDU is logically divided into blocks of given 
ARQ_BLOCK_SIZE. The last block of a DLC SDU may be smaller than ARQ_BLOCK_SIZE. Once defined, the 
block never changes. 

This value of the ARQ_BLOCK_SIZE TLV specifies the ARQ block size. This parameter is negotiated upon 
connection setup. The DSA-REQ shall contain the suggested value of this parameter. The DSA-RSP message shall 
contain the confirmation value or an alternate value for this parameter. 
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A set of blocks selected for transmission or retransmission is encapsulated into a PDU. A PDU may contain blocks that 
are transmitted for the first time as well as retransmitted blocks. If fragmentation is enabled for this connection, the 
fragmentation shall occur only on ARQ block boundaries. If a PDU is not packed, all the blocks in that PDU must have 
contiguous block numbers. When a PDU is packed, any sequence of blocks between DLC subheaders and the sequence 
of blocks after the last packing subheader must have contiguous block numbers. 

If ARQ is enabled at the connection. Fragmentation and Packing subheaders contain a BSN, which is the sequence 
number of the first ARQ block in the sequence of blocks following this subheader. It is a matter of transmitter's policy 
whether a set of blocks once transmitted as a single PDU should be retransmitted also as a single PDU or not. Figure 4 
illustrates the use of blocks for ARQ transmissions and retransmissions; two options for retransmission presented: with 
and without rearrangements of blocks. 
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Retransmission of PDU without rearrangement 
Figure 4: Block usage examples for ARQ transmissions and retransmissions 

8.4.2 Comparison of BSNs 

As numbers assigned to blocks occasionally wrap around zero, BSNs cannot be compared by directly comparing their 
values. Instead, both BSNs need to be normalized before a comparison can be made. Normalization of a BSN on the 
transmit side is accomplished using the expression: 



bsn' = (bsn - BSN_base) mod ARQ_BSN_MODULUS 

The base values for the receiver and transmitter state machines are ARQ_TX_WINDOW_START and 
ARQ_RX_WINDOW_START, respectively. 



(11) 



ETSI 



61 



ETSI TS 102 178 VI .3.1 (2006-02) 



8.4.3 Transmitter state machine 

An ARQ block may be in one of the following three states: Not-sent, Outstanding, Discarded, Waiting-for-retransmit. 
Any ARQ block begins as Not-sent, and transfers to other states as shown in figure 5. 

For a given connection, the transmitter shall first handle (transmit or discard) blocks in Waiting-far- retransmit state and 
only then blocks in Not-sent state. Blocks in Outstanding, Discarded, or Done state shall not be transmitted. When 
blocks are retransmitted, the block with the lowest FSN shall be retransmitted first. 

When a block in not-sent state is included in a DLC PDU, it is assigned the current value of ARQ_TX_NEXT_BSN, 
which is then incremented. 




ARQ_FRAGMENT_LIFETIME 



Figure 5: Transmitter ARQ state machine 

When any acknowledgement is received, the transmitter shall check the validity of the BSN(s). A BSN is valid if: 

ARQ_TX_WINDOW_START <BSN <ARQ_TX_NEXT_BSN-1 (12) 

If the BSN is invalid, the transmitter shall ignore the acknowledgement. All timers associated with acknowledged 
blocks shall be cancelled. 

When a cumulative acknowledgement with a valid BSN is received, the transmitter shall consider all blocks in the 
interval ARQ_TX_WINDOW_START to BSN (inclusive) as acknowledged and set ARQ_TX_WINDOW_START to 

BSN+1. 

When a selective acknowledgement is received, the transmitter shall consider as acknowledged all blocks so indicated 
by the entries in the bitmap for valid BSN values. As the bitmap entries are processed in increasing BSN order, 
ARQ_TX_WINDOW_START shall be incremented each time the BSN of an acknowledged block equals 
ARQ_TX_WINDOW_START. 

When ARQ_TX_WINDOW_START has been advanced by either of the above methods and acknowledgement of 
reception has already been received for the fragment with the BSN value now assigned to 

ARQ_TX_WINDOW_START, the value of ARQ_TX_WINDOW_START shall be incremented until a BSN value is 
reached for which no acknowledgement has been received. 

A bitmap entry not indicating A bitmap entry not indicating acknowledgement shall be considered a NACK for the 
corresponding blocks. 

When a cumulative with selective acknowledgement with a valid BSN is received, the transmitter performs the actions 
described above for cumulative acknowledgement, followed by those for a selective acknowledgement. 

All timers associated with acknowledged blocks shall be cancelled. 

A Discard message shall be sent following violation of ARQ_BLOCK_LIFETIME. The message may be sent 
immediately or may be delayed up to ARQ_RX_PURGE_TIMEOUT + ARQ_RETRY_TIMEOUT. Following the first 
transmission, subsequent discard orders shall be sent to the receiver at intervals of ARQ_RETRY_TIMEOUT until an 
acknowledgment to the discarded BSN has been received. Discard orders for adjacent BSN values may be accumulated 
in a single Discard message. 
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8.4.4 Receiver state machine 



When a PDU is received, its integrity shall be determined based on the CRC-32 checksum. If a PDU passes the 
checksum, it is unpacked and de -fragmented, if necessary. The receiver maintains a sliding-window defined by 
ARQ_RX_WINDOW_START state variable and the ARQ_WINDOW_SIZE parameter. When an ARQ block with a 
number that falls in the range defined by the sliding window is received, the receiver shall accept it. ARQ blocks with 
numbers outside the sliding window shall be rejected. The receiver should discard duplicate ARQ blocks (i.e. ARQ 
blocks that where already received correctly) within the window. 

The sliding window is maintained such that the ARQ_RX_WINDOW_START variable always points to the lowest 
numbered ARQ block that has not been received or has been received with errors. When an ARQ block with a number 
corresponding to the ARQ_RX_WINDOW_START is received, the window is advanced (i.e. ARQ_RX_ WINDOW. 
START is incremented modulo ARQ_BSN_MODULUS) such that the ARQ_RX_WINDOW_START variable points 
to the next lowest numbered ARQ block that has not been received or has been received with errors. The timer 
associated with ARQ_SYNC_LOSS_TIMEOUT shall be reset. 

As each block is received, a timer is started for that block. When the value of the timer for a block exceeds 
ARQ_RX_PURGE_TIMEOUT, the timeout condition is marked. When this occurs, ARQ_RX_WINDOW_START is 
advanced to the BSN of the next block not yet received after the marked block. Timers for delivered blocks remain 
active and are monitored for timeout until the BSN values are outside the receive window. 

When ARQ_RX_WINDOW_START is advanced, any BSN values corresponding to blocks that have not yet been 
received residing in the interval between the previous and current ARQ_RX_WINDOW_START value shall be marked 
as received and the receiver shall send an ARQ Feedback IE to the transmitter with the updated information. Any 
blocks belonging to complete SDUs shall be delivered. Blocks from partial SDUs shall be discarded. 

When a discard message is received from the transmitter, the receiver shall discard the specified blocks, advance 
ARQ_RX_WINDOW_START to the BSN of the first block not yet received after the BSN provided in the Discard 
message, and mark all not received blocks in the interval from the previous to new ARQ_RX_WINDOW_START 
values as received for ARQ feedback IE reporting. 

For each ARQ block received, an acknowledgment shall be sent to the transmitter. Acknowledgment for blocks outside 
the sliding window shall be cumulative. Acknowledgments for blocks within the sliding window may be either for 
specific ARQ blocks (i.e. contain information on the acknowledged ARQ block numbers), or cumulative (i.e. contain 
the highest ARQ block number below which all ARQ blocks have been received correctly) or a combination of both 
(i.e. cumulative with selective). Acknowledgments shall be sent in the order of the ARQ block numbers they 
acknowledge. The frequency of acknowledgement generation is not specified here and is implementation dependent. 

A DLC SDU is ready to be handed to the upper layers when all of the ARQ blocks of the DLC SDU have been 
correctly received within the time-out values defined. 

When ARQ_DELIVER_IN_ORDER is enabled, a DLC SDU is handed to the upper layers as soon as all the ARQ 
blocks of the DLC SDU have been correctly received within the defined time-out values and all blocks with sequence 
numbers smaller than those of the completed message have either been discarded due to time-out violation or delivered 
to the upper layers. 

When ARQ_DELIVER_IN_ORDER is not enabled, DLC SDUs are handed to the upper layers as soon as all blocks of 
the DLC SDU have been successfully received within the defined time-out values. 

The actions to be taken by the receiver state machine when an ARQ Reset message is received are provided in figure 4. 
The actions to be taken by the receiver state machine when it wants to initiate a reset of the transmitter ARQ state 
machine are provided in figure 5. Synchronization of the ARQ state machines is governed by a timer managed by the 
receiver state machine. Each time ARQ_RX_WINDOW_START is updated, the timer is set to zero. When the timer 
exceeds the value of ARQ_SYNC_LOSS_TIMEOUT the receiver state machine shall initiate a reset of the connection's 
state machines as described in figure 5. 
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Figure 6: ARQ block reception 

8.4.5 Resetting the ARQ state machine 

Synchronization of the ARQ state machines is governed by timers managed by the transmitter and receiver state 
machine. Each time ARQ_TX_WINDOW_START is updated, the transmitter timer is reset (set to zero). Each time 
ARQ_RX_WINDOW_START is updated, the transmitter timer is reset. 

When the timer exceeds the value of ARQ_SYNC_LOSS_TIMEOUT the state machine shall initiate the ARQ Reset 
process for that connection. The process of executing an ARQ Reset on a connection is shown in figures 7 and 8. 
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Figure 7: Receiver initiated ARQ Reset 
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Figure 8: Transmitter initiated ARQ Reset 



8.5 ARQ service flow TLVs 

The following TLV encodings shall be available. 
ARQ SUPPORT: 

• The ARQ SUPPORT indicates whether or not ARQ is supported by the system. When the system supports 
ARQ, this TLV shall be included in the REG-REQ by the SS whereas the BS shall indicate acceptance or 
rejection of the ability. ARQ shall be available for connections only if both sides support it. 

ARQ ENABLE: 

• The ARQ ENABLE TLV indicates whether or not ARQ is available for the connection that is being setup. The 
DSA-REQ shall contain the request to use ARQ or not. The DSA-RSP message shall contain the acceptance or 
rejection of the request. ARQ shall be enabled for this connection only if both sides support it. When a 
DSA-REQ is issued by the BS, the use of ARQ may be mandated for the requested connection (if ARQ 
availability was confirmed during registration). In that case, the SS shall either reject the connection or accept 
the connection with ARQ. 
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ARQ WINDOW SIZE: 



• This parameter is negotiated upon connection setup. The DSA-REQ/DSC-REQ message shall contain the 

suggested value for this parameter. The DSA-RSP/DSC-RSP message shall contain the confirmation value or 
an alternate value for this parameter. The smaller of the two shall be used as the actual 
ARQ_WINDOW_SIZE. 

ARQ RETRY TIMEOUT: 



• 



• 



The ARQ retry timeout should account for the transmitter and receiver processing delays and any other delays 
relevant to the system. This is achieved through the use of the following two TLVs: 

ARQ_TX_DELAY: This is the total estimated transmitter delay, including sending (e.g. DLC PDUs) and 
receiving (e.g. ARQ feedback) delays and other implementation dependent processing delays. If the 
transmitter is the BS, it may include other delays such as scheduling and propagation delay. 

ARQ_RX_DELAY: This is the total estimated receiver delay, including receiving (e.g. DLC PDUs) and 
sending (e.g. ARQ feedback) delays and other implementation dependent processing delays. If the 
receiver is the BS, it may include other delays such as scheduling and propagation delay. 

The DSA-REQ and DSA-RSP messages shall contain the values for these parameters, where the receiver and 
transmitter each declare their capabilities. When the DSA handshake is completed, each party shall calculate: 



ARQ_RETRY_TIMEOUT = ARQ_TX_DELAY + ARQ_RX_DELAY (13) 

ARQ BLOCK LIFETIME: 

• The BS shall set this parameter. The DSA-REQ or DSA-RSP messages shall contain the value of this 
parameter as set by the BS. If this parameter is set to 0, then the ARQ_BLOCK_LIFETIME value shall be 
considered infinite. 

ARQ_SYNC_LOSS_TIMEOUT: 

• The BS shall set this parameter. The DSA-REQ or DSA-RSP messages shall contain the value of this 
parameter as set by the BS. If this parameter is set to 0, then the ARQ_SYNC_LOSS_TIMEOUT value shall 
be considered infinite. 

ARQ_DELIVER_IN_ORDER: 

• The transmitter shall set this parameter. The DSA-REQ or DSA-RSP messages shall contain the value of this 
parameter. This TLV indicates whether or not data is to be delivered by the receiving DLC to its client 
application in the order in which the data was handed off to the originating DLC. 

ARQ_RX_PURGE_TIMEOUT: 

• The BS shall set this parameter. The DSA-REQ or DSA-RSP messages shall contain the value of this 
parameter as set by the BS. If this parameter is set to 0, then the ARQ_RX_PURGE_TIMEOUT value shall be 
considered infinite. 
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Table 78: ARQ TLVs 



Name 


Type 


Length 


Value 


Scope 


ARQ_SUPPQRT 


5.21 


1 


0: No ARQ support capability 

1 to 254: IVIax. simultaneous connections for 

which ARQ can be supported 
255: 255 or more simultaneously 

supportable ARQ connections 


REG-REQ 
REG-RSP 


ARQ_ENABLE 


[24/25]. 11 


1 


= ARQ not support 

1 = ARQ supported 

2 = ARQ mandated (BS in DSA-REQ only) 


DSA-REQ 
DSA-RSP 


ARQ_WINDOW_SIZE 


[24/25]. 12 


2 


1 -{ARQ_BSN_MQDULUS/2) 


DSx-REQ 
DSx-RSP 


ARQ_TX_DELAY 


[24/25]. 13 


2 


Estimated transmitter delay 
to 655 350 (10 |js granularity) 


DSA-REQ 
DSA-RSP 


ARQ_RX_DELAY 


[24/25]. 22 


2 


Estimated receiver delay 

to 655 350 (10 |js granularity) 


DSA-REQ 
DSA-RSP 


ARQ_BLQCK_LIFETIME 


[24/25]. 17 


2 


= Infinite 

1 to 655 350 (10 MS granularity) 


DSA-REQ 
DSA-RSP 


ARQ_SYNC_LOSS_TIMEOUT 


[24/25]. 19 


2 


= Infinite 

1 to 655 350 (10 MS granularity) 


DSA-REQ 
DSA-RSP 


ARQ_DELIVER_IN_QRDER 


[24/25]. 20 


1 


= Order of delivery is not preserved 

1 = Qrder of delivery is preserved 


DSA-REQ 
DSA-RSP 


ARQ_RX_PURGE_TIMEOUT 


[24/25]. 21 


2 


= Infinite 

1 to 655 350 (10 MS granularity) 


DSA-REQ 
DSA-RSP 


ARQ_BLQCK_SIZE 


[24/25].22 


1 


Length of ARQ block, bytes 


DSA-REQ 
DSA-RSP 



Mesh topology support 



9.1 



Introduction 



The main difference between the PMP and optional Mesh modes is that in the PMP mode, traffic only occurs between 
the BS and SSs, while in the Mesh mode traffic can be routed through other SSs and can occur directly between SSs. 
Depending on the transmission protocol algorithm used, sharing of channel resources can be done on the basis of 
equality using distributed scheduling, or on the basis of superiority of the mesh BS, which effectively results in 
centralized scheduling, or on a combination of both. 

Where optional mesh systems are addressed, a system consists of an DLC and PHY implementation with at least two 
mesh nodes communicating via a multipoint-to-multipoint radio air interface, along with the interfaces to external 
networks and services transported by the DLC and PHY. 

Within a mesh network, a system that has a direct connection to backhaul services outside the mesh network, is termed 
a mesh BS. All the other systems of a mesh network are termed mesh SS. In general, the systems of a mesh network are 
termed nodes. Within mesh context, uplink and downlink are defined as traffic in the direction of the mesh BS and 
traffic away from the mesh BS respectively. 

The other three important terms of mesh systems are neighbour, neighbourhood and extended neighbourhood. The 
stations with which a node has direct links are called neighbours. Neighbours of a node shall form a neighbourhood. A 
node's neighbours are considered to be "one hop" away from the node. An extended neighbourhood contains, 
additionally, all the neighbours of the neighbourhood. 

Using distributed scheduling, all the nodes including the mesh BS shall coordinate their transmissions in their two-hop 
neighbourhood and shall broadcast their schedules (available resources, requests and grants) to all their neighbours. 
Optionally the schedule may also be established by directed un-coordinated requests and grants between two nodes. 
Nodes shall ensure that the resulting transmissions do not cause collisions with the data and control traffic scheduled by 
any other node in the two-hop neighbourhood. There is no difference in the mechanism used in determining the 
schedule for downlink and uplink. 
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In the mode of operation with centralized scheduHng, resources are granted in a more centralized manner. The mesh BS 
shall gather resource requests from all the mesh SSs within a certain hop range. It shall determine amount of granted 
resources for each link in the network both in downlink and uplink, and communicates these grants to all the mesh SSs 
within the hop range. The grant messages do not contain the actual schedule but each node shall compute it by using the 
predetermined algorithm with given parameters. 

All the communications are in the context of a link, which is established between two nodes. One link shall be used for 
all the data transmissions between the two nodes. QoS is provisioned over links on a message by message basis. No 
service or QoS parameters are associated with a link but each unicast message has service parameters in the header. 
Traffic classification and flow regulation are performed at ingress node by upper-layer classification/regulation 
protocol. The service parameters associated with each message shall be communicated together with the message 
content via the DLC SAP. 

Mesh systems typically use omni directional or 360° steerable antennas, but can also be co-located using sector 
antennas. At the edge of the coverage area of the mesh network, where only a connection to a single point is needed, 
even highly directional antennas can be used. 



9.2 Addressing and connections 



Each node shall have a 48-bit universal MAC Address. The address uniquely defines the node from within the set of all 
possible vendors and equipment types. This address is used during the network entry process and as part of the 
authorization process by which the candidate node and the network verify the identity of each other. 

When authorized to the network the candidate node shall receive a 16-bit Node Identifier (Node ID) upon a request to 
the mesh BS. Node ID is the basis for identifying nodes during normal operation. The Node ID is transferred in the 
Mesh subheader, which follows the Generic DLC header, in both unicast and broadcast messages. 

For addressing nodes in the local neighbourhood, 8-bit link identifiers (Link IDs) shall be used. Each node shall assign 
an ID for each link it has established to its neighbours. The Link IDs are communicated during the Link Establishment 
process as neighbouring nodes establish new links. The Link ID is transmitted as part of the CID in the Generic DLC 
header in unicast messages. The Link IDs shall be used in distributed scheduling to identify resource requests and 
grants. Since these messages are broadcast, the receiver nodes shall be able to identify the schedule of their own using 
both the transmitter's Node ID in the Mesh subheader, and the Link ID in the MSH-DSCH payload. 

After entering the network, a node can establish links with nodes other than its sponsor by following the secure process 
as defined in table 79. This process uses the MSH-NCFG Neighbour Link Establishment IE (see table 64). 

1) Node A sends a challenge (action code = 0x0) containing: 

HMAC{ Operator Shared Secret, frame number. Node ID of node A, Node ID of node B } (14) 

in which the Operator Shared Secret is a private key obtained from the provider (which is also used to enter the 
network) and the frame number is the last known frame number in which Node B send a MSH-NCFG 

message. 

2) Node B, upon reception, computes the same value (it may also attempt some earlier frame numbers in which it 
sent MSH-NCFG messages, in case node A missed the last of its MSH-NCFGs) as above and compares. If the 
values do not match, a rejection (action code = 0x3) is returned. If a match is achieved. Node B sends, 
implicitly accepting the link, a challenge response (action code = 0x1) containing: 

HMAC{Operator Shared Secret, frame number. Node ID of node B, Node ID of node A} (15) 

in which the frame number is the frame number in which Node A sent the MSH-NCFG message with 
challenge. It also randomly selects and includes an unused link ID, which shall from this point forward 
indicate the link from node B to node A. 

3) Node A, upon reception, computes the same value as above and compares. If the values do not match a 
rejection (action code = 0x3) is returned. If a match is achieved. Node A sends an Accept. It also randomly 
selects and includes an unused link ID, which shall from this point forward indicate the link from node A to 
node B. 
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Table 79: Link establishment 
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NodeB 
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Action Code = Challenge 
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The Connection ID in mesh mode is specified as shown in table 80 to convey broadcast/unicast, service parameters and 
the link identification. 

Table 80: Connection ID 



Syntax 


Size 


Notes 


CIDQ { 






if (Xmt Link ID == OxFF) { 






Logical Network ID 


8 bits 


0x00 All-net Broadcast 


} else { 






Type 


2 bits 


0x0 DLC Management 

0x1 IP 

0x2 to 0x3 Reserved 


Reliability 


1 bit 


0x0 No retransmissions 
0x1 Up to 4 retransmissions 


Priority/Class 


3 bits 


Indicates message class 


Drop Precedence 


2 bits 


Messages with larger Drop Precedence shall have 
higher dropping likelihood during congestion 


} 






Xmt Link ID 


8 bits 


OxFF DLC management broadcast 


} 







9.3 



DLC service definition 



9.3.1 Primitives 

The following primitives are supported at the DLC Service Access Point in mesh mode: 
MAC_CREATE_CONNECTION.indication. 
MAC_CHANGE_CONNECTION.indication. 
MAC_TERMINATE_CONNECTION.request. 
MAC_TERMINATE_CONNECTION.indication. 
MAC_DATA.request. 
MAC_DATA.indication. 
MAC_FORWARDING_UPDATE.request. 
MAC FORWARDING UPDATE.indication. 
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In mesh mode none of the actions cause the initiating CS to send a REQUEST primitive to its DLC sublayer. They are 
either indications of the results from the processes handled by the DLC CPS management entity, or data delivery 
actions needed to convey information to the peer CS. 

9.3.2 MAC_CREATE_CONNECTION. indication 

Function: 

• This primitive is issued by a DLC entity to the CS, to report a new link established to a neighbour node. 
Generation: 

• This primitive is generated whenever a new link has been established to a neighbour node. 
Effect of receipt: 

• The receipt of the primitive is an indication to the CS that a link to the given neighbour node is up and can be 
used for data delivery. 

Semantics: 

MAC_CREATE_CONNECT ION. indication 
{ 

CID, 

max length, 

service flow parameters, 
encryption flag 
} 

• The CID is the Connection ID in Mesh as conveyed in the Generic DLC header. 

• The max length parameter specifies the maximum length of SDUs that are allowed over the link. 

• The service flow parameters include information on: 

Data rate (Mbps): 

■ Data rate associated with the burst profile for the physical link over which the connection is 
created. 

Transmit power (dB): 

■ Transmit power at the antenna port for the physical link over which the connection is created. 

• Estimate of packet error rate for 256-byte packets: 

The encryption flag specifies that the data carried over this link is encrypted, if ON, If OFF, then no 
encryption is used. 

9.3.3 MAC_CHANGE_CONNECTION. indication 

Function: 

• This primitive is issued by a DLC entity to the CS, to report new parameters of an existing link to a neighbour 
node. 

Generation: 

• This primitive is generated whenever parameters of an existing link has changed. 
Effect of receipt: 

• The CS shall take into account new link parameters in the use of the link. 
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Semantics: 

MAC_CHANGE_CONNECTION. indication 
{ 

CID, 

max length, 
service parameters, 
encryption flag 
} 

• The CID is the Connection ID in Mesh as conveyed in the Generic DLC header. 

• The max length parameter specifies the maximum length of SDUs that are allowed over the link. 

• The service parameters include information on: 

Target data rate for the link in Mbps. 

Transmit energy for the link. 

Estimate of packet error rate for 256-byte packets. 

The encryption flag specifies that over this link encryption is possible, if ON, If OFF, then no encryption 
is possible. 

9.3.4 MAC_TERMINATE_CONNECTION. request 

Function: 

• This primitive is issued by a CS, to terminate an existing link to a neighbour node. 
Generation: 

• This primitive is generated to bring down an existing link to a neighbour node. 
Effect of receipt: 

• The receipt of the primitive causes the DLC to terminate the connection and report that to the DLC entity in 
the neighbour the link was to. 

Semantics: 

MAC_TERMINATE_CONNECTION. request 
{ 

CID 
} 

• The CID is the Connection ID in Mesh as conveyed in the Generic DLC header. 

9.3.5 MAC_TERMINATE_CONNECTION. indication 

Function: 

• This primitive is issued by the DLC entity of the non-initiating side to indicate termination of the link to a 
neighbour node. 

Generation: 

• This primitive is generated by the DLC sublayer when it receives an indication in a MSH-NCFG message. 
Effect of receipt: 

• The receipt of the primitive is an indication to the CS that the link to the given neighbour node is down and 
cannot be used for data delivery. 
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Semantics: 

MAC_TERMINATE_CONNECTION. indication 
{ 

CID, 
} 

• The CID is the Connection ID in Mesh as conveyed in the Generic DLC header. 

9.3.6 MAC_D ATA. request 

Function: 

• This primitive defines the transfer of data to the DLC entity from a convergence sublayer service access point. 
Generation: 

• This primitive is generated by a convergence sublayer whenever an DLC SDU is to be transferred to a peer 
entity. 

Effect of receipt: 

• The receipt of the primitive causes the DLC entity to process the DLC SDU through the DLC sublayer and 
pass the appropriately formatted PDUs to the PHY layer for transfer to the peer DLC sublayer entity, using the 
Node ID specified. 

Semantics: 

MAC_DATA. request 



{ 



CID, 

length, 

data, 

encryption flag 



The CID is the Connection ID in Mesh as conveyed in the Generic DLC header. 

The length parameter specifies the length of the DLC SDU in bytes. 

The data parameter specifies the DLC SDU as received by the local DLC entity. 

The priority/class parameter embedded in the CID specifies priority class of the DLC SDU. 

The reliability parameter embedded in the CID specifies maximum number of transmission attempts at each 
hnk. 

The drop precedence parameter embedded in the CID indicates relative MSDU dropping likelihood. 

The encryption flag specifies that the data sent over this link is to be encrypted, if ON. If OFF, then no 
encryption is used. 

9.3.7 MAC_DATA.indication 

Function: 

• This primitive defines the transfer of data from the DLC to the convergence sublayer. 
Generation: 

• This primitive is generated whenever an DLC SDU is to be transferred to a peer convergence entity. 
Effect of receipt: 

• The effect of receipt of this primitive by a convergence entity is dependent on the validity and content of the 
DLC SDU. 
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Semantics: 

MACJATA. request 



CID 

length, 

data, 

reception status, 

encryption flag 



• The CID is the Connection ID in Mesh as conveyed in the Generic DLC header. 

• The length parameter specifies the length of the DLC SDU in bytes. 

• The data parameter specifies the DLC SDU as received by the local DLC entity. 

• The reception status parameter indicates transmission success or failure for those PDUs received via the 
MAC_DATA.indication. 

9.3.8 MAC_FORWARDING_UPDATE.request 

Function: 

• This primitive defines the transfer of the centralized scheduling configuration to the DLC entity from a 
convergence sublayer service access point in the mesh BS. 

Generation: 

• This primitive is generated in the mesh BS whenever it has changed the schedule tree. 
Effect of receipt: 

• The receipt of this primitive causes the DLC to generate a MSH-CSCF message with the given information. 
The message shall be distributed to all the nodes listed in the tree. 

Semantics: 

• The parameters of the primitive are as follows: 

MAC_FORWARDING_UPDATE . request 
{ 

number of nodes, 

node parameters [number of nodes] 
} 

• The number of nodes parameter indicates number of nodes in the scheduling tree of this mesh BS. 

• The node parameters entry shall contain the following information: 

Node ID: The Node ID parameter indicates the node. 

Number of children: The number of nodes parameter indicates number of children the given node. 

Child parameters [number of children] . 

Each child parameters entry shall containing the following information: 

■ child index: The child index indicates index into the list of Node IDs; 

■ uplink burst profile: The uplink burst profile indicates burst profile of link to child node; 

■ downlink burst profile: The downlink burst profile indicates burst profile of link from child node. 
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9.3.9 MAC_FORWARDING_UPDATE.indication 

Function: 

• This primitive defines the transfer of the centralized scheduling configuration from the DLC to the 
convergence sublayer. 

Generation: 

• This primitive is generated by the DLC sublayer at all the nodes, which have received the MSH-CSCF 
message, when new centralized schedule with revised schedule tree takes effect. 

Effect of receipt: 

• The receipt of this primitive synchronizes the forwarder and DLC scheduler to routing changes. 
Semantics: 

MAC_FORWARDING_UPDATE . indication 
{ 

Node ID self 
number of nodes, 

node parameters [number of nodes] 
} 

• The Node ID self indicates the Node ID of the node itself. 

• The number of nodes parameter indicates number of nodes in the scheduling tree of this mesh BS. 

• The node parameters entry shall contain the following information: 

Node ID: The Node ID parameter indicates the node. 

Number of children: The number of nodes parameter indicates number of children the given node. 

Child parameters [number of children] . 

Each child parameters entry shall contain the following information: 

■ child index: The child index indicates index into the list of Node IDs; 

■ uplink burst profile: The uplink burst profile indicates burst profile of link to child node; 

■ downlink burst profile: The downlink burst profile indicates burst profile of link from child node. 

9.4 DLC management message applicability 

When implementing the mesh mode, all clauses referring to the mesh mode in the standard shall apply as mandatory. 
Basic functionalities are mandatory for a mesh node as they are for a PMP node, except those that are stated as optional 
below. 

For a mesh-enabled system, the messages below and the corresponding functionality are always mandatory to 
implement: 

MSH-NCFG. 

MSH-NENT. 

MSH-DSCH. 

MSH-CSCH. 

MSH-CSCF. 

REG-REQ. 
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REG-RSP. 

PKM-REQ. 

PKM-RSP. 

SBC-REQ. 

SBC-RSP. 

TFTP-CPLT. 

TFTP-RSP. 

RES-CMD. 

For a mesh enabled system, the following messages and the corresponding functionality are mandatory/optional 
whenever they are correspondingly optional/mandatory for a PMP system: 

ARQ-Feedback. 

AAS-FBCK-REQ. 

AAS-FBCK-RSP. 

When operating in the mesh mode, the messages below and the corresponding functionality are not used: 

DL-MAP. 

DCD. 

DSC-ACK. 

DSC-REQ. 

DSC-RSP. 

DSD-RSP. 

DSX-RVD. 

UCD. 

UL-MAP. 

CLK-CMP. 

DBPC-REQ. 

DBPC-RSP. 

DREG-CMD. 

MCA-REQ. 

MCA-RSP. 

RNG-REQ. 

RNG-RSP. 

DSA-ACK. 

DSA-REQ. 

DSA-RSP. 
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9.5 Network synchronization 



Network configuration (MSH-NCFG) and network entry (MSH-NENT) packets provide a basic level of communication 
between nodes in different nearby networks whether from the same or different equipment vendors or wireless 
operators. These packets are used to synchronize both centralized and distributed control mesh networks. 

This communication is used to support basic configuration activities such as: synchronization between nearby networks 
used (for instance, for multiple, co-located BSs to synchronize their uplink and downlink transmission periods), 
communication and coordination of channel usage by nearby networks, and discovery and basic network entry of new 
nodes. 

MSH-NCFG, MSH-NENT and MSH-DSCH can all assist a node in synchronizing to the start of frames. For these 
messages, the control subframe, which initiates each frame, is divided into transmit opportunities (see TS 102 177 [2]). 
The first transmit opportunity in a network control subframe may only contain MSH-NENT messages, while the 
remainder MSH_CTRL_LEN-1 may only contain MSH-NCFG messages. In scheduling control subframes, the 
MSH-DSCH_NUM transmit opportunities assigned for MSH-DSCH messages come last in the control subframe. The 
MSH-NCFG messages also contain the number of its transmit opportunity, which allows nodes to easily calculate the 
start time of the frame. 



9.5.1 Physical neighbour list 



All the basic functions like scheduling and network synchronization are based on the neighbour information all the 
nodes in the mesh network shall maintain. Each node (BS and SS) maintains a physical neighbourhood list with each 
entry containing the following fields: 

MAC Address 

• 48-bit MAC address of the neighbour. 
Hop Count 

• Indicates distance in hops of this neighbour from the present node. If a packet has been success-fully received 
from this neighbour recently (defined further below), it is considered to be 1 hop away. 

Node Identifier 

• 16-bit Number used to identify this node in a more efficient way in MSH-NCFG messages. 
XmtHoldoffTime 

• The minimum number of MSH-NCFG transmit opportunities that no MSH-NCFG message transmission is 
expected from this node after Next Xmt Time (see for detailed definition). 

Next Xmt Time 

• The MSH-NCFG transmit opportunity(ies) in which the next MSH-NCFG from this node is expected (see for 
detailed definition). 

Reported Flag 

• Set to TRUE if this Next Xmt Time has been reported by this node in a MSH-NCFG packet. Else set to 
FALSE. 

Synchronization hop count 



• 



This counter is used to determine superiority between nodes when synchronizing the network. Nodes can be 
assigned as master time keepers, which are synchronized externally (for example using GPS). These nodes 
transmit Synchronization hop count of 0. Nodes shall synchronize to nodes with lower synchronization hop 
count, or if counts are the same, to the node with the lower Node ID. 
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The Physical Neighbourhood List is updated as follows when a MSH-NCFG packet is received from a neighbour: 

• The hop count field in the Physical Neighbourhood List for the neighbour itself is set to 1 . The hop count field 
for other nodes listed in the MSH-NCFG message is set to Hops to Neighbour +2 (see table) unless they are 
already listed with a lower hop count. 

• The Next Xmt Time and Xmt Holdoff Time of the neighbour and all nodes listed in the MSH-NCFG are 
updated. 

• The "Reported Flag" for each entry in the Physical Neighbour table which was modified is set to FALSE. 

9.5.2 MSH-NCFG/MSH-NENT transmission cinannel and timing 

MSH-NCFG and MSH-NENT packets are scheduled for transmission during control subframes. So that all nearby 
nodes receive these transmissions, the channel used is cycled through the available channels in the band, with the 
channel selection being based on the Frame number. So, for Frame Number /, the channel is determined by the array 
lookup: 



NetConfigChannel = Logical channel list 



Frame Number 



Scheduling Frames x 4 + 1 



modNum Channels 



(16) 



where the Logical channel List and Scheduling Frames are derived from the MSH-NCFG:Network Descriptor 
(see table 60). 

9.5.2.1 MSH-NCFG next transmission scheduling 

During the current Xmt Time of a node (i.e. the time slot when a node transmits its MSH-NCFG packet), the node uses 
the following pseudo-code procedure to determine its Next Xmt Time: 

Order its physical neighbour list by Next Xmt Time. 
For each entry in the neighbour list; 

Entry's Earliest Subsequent Xmt Time = Entry's Next Xmt Time + Entry's Xmt Holdoff Time 
Success = FALSE; 

TempXmtTime = Xmt Time + Xmt Holdoff Time 
While (Success == FALSE) do { 

Determine the eligible competing nodes, which is the set of all nodes in the physical- 
neighbour list for which: 

TempXmtTime cz Entry's Next Xmt Time eligibility interval (see equation 2); OR 
Entry's Earliest Subsequent Xmt Time < TempXmtTime. 

if ( MeshElection (TempXmtTime, MyNodelD, CompetingNodelDsList [ ] == FALSE) 

Set TempXmtTime equal to the next MSH-NCFG Xmt opportunity, 
else ; 

Success = TRUE 
Next Xmt Time =TempXmtTime . 
} 

The Mesh Election procedure determines whether the local node is the winner for a specific TempXmtTime among all 
the competing nodes. It returns TRUE if the local node wins or FALSE otherwise. The algorithm works as follows: 

boolean MeshElection (uint32 XmtTime, uintl6 MyNodelD, uintl6 NodelDList [ ] )) { 
uint32 nbr_smear_val, smear_vall, smear_val2; 
smear_vall =inline_smear (MyNodelD ^ XmtTime )); 
smear_val2 =inline_smear (MyNodelD iXmtTime ); 
For each Node ID nbrsNodelD in NodelDList Do { 

nbr_smear_val =inline_smear (nbrsNodelD ^ XmtTime ) ) ; 
if (nbr_smear_val >smear_vall ) ( 

return FALSE; //This node loses. 
} 

else if (nbr_smear„val ==smear_vall ) ( 
//1st tie-breaker. 

nbr_smear_val =inline_smear (nbrsNodelD IXmtTime ) ; 
if (nbr_smear_val >smear__val2 ) ( 

return FALSE; //This node loses. 
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else if (nbr_smear_val ==smear_val2 ) { 

//If we still collide at this point Break the tie based on MacAdr 
if ( (XmtTime is even && (nbrsNodelD >MyNodeID) ) 1 \ 
(XmtTime is odd && (nbrsNodelD <MyNodeID ) ) ) { 
return FALSE; //This node looses. 



//This node won over this competing node 
}//End for all competing nodes 
//This node is winner, it won over all competing nodes, 
return TRUE; 
} 

// Convert a uniform 16-bit value to an uncorrelated uniform 16-bit hash value, uses mixing. 

uint32 inline_smear (uint 16 val) ( 
val += (val <<12) ; 
val ^= (val >>22) ; 
val += (val <<4) ; 
val ^= (val >>9) ; 
val += (val <<10) ; 
val ^= (val >>2) ; 
val += (val <<7) ; 
val '~= (val >>12) ; 
return (val) ; 



9.5.2.2 MSH-NENT next transmission scheduling 

The NetEntry scheduling protocol provides the upper layer protocol an unreliable mechanism to access the NetEntry 
slot(s), so that new nodes, which are not yet fully-functional members of the network, can communicate with the 
fully-functional members of the network. 

In the NetEntry slots new nodes shall transmit MSH-NENT messages using the following two step procedure: 

1) The initial MSH-NENT packet with request IE is sent in a random, contention-based fashion in a free network 
entry transmission slot in the immediately following MSH-NENT transmission opportunity after the targeted 
sponsor sends a MSH-NCFG. with sponsored MAC Address 0x000000000000. 

2) After the sponsor advertises the new nodes MAC Address in a MSH-NCFG message, the new node may send 
a MSH-NENT in the immediately following MSH-NENT transmission opportunity. 

A new node uses the algorithm specified by the following pseudocode to access NetEntry transmission slots; 

/^Variable Definitions */ 

Pkt *MSH-NENT_MsgQ =NULL; //MSH-NENT Message queue 

uint SponsorsState =UNAVAILABLE; //SponsorsState and OthersState record the NetEntry 

uint OthersState =BUSY; 

// Address in the MSH-NCFG packet form the sponsor or other nodes, 

// which can be used to determine the availability of the next NetEntry transmission opportunity 

//SponsorsState can be UNAVAILABLE, AVAILABLE and POLLING. 

//OthersState can be AVAILABLE and BUSY. 

uint OthersMaxMacAdr =OxFFFFFFFF; 

uint OthersMinMacAdr =0x00000000; 

void RecvOutgoingMSH-NENT_Msg (Pkt *MSH-NENT_Msg) { 

MSH-NENT_MsgQ->enqueue (MSH-NENT_Msg) ; 
} 

void RecvIncomingMSH-NCFG_Msg (Pkt *MSH-NCFG_Msg) { 

if (MSH-NCFG_Msg->sourceMacAdr ==sponsorsMacAdr ) { 
switch (MSH-NCFG_Msg->NetEntryAddress) 
{ 

case 0x000000000000: SponsorsState =AVAILABLE; break; 
case myMacAdr: SponsorsState =POLLING; break; 

default: break; 

} 
} else { 

switch (MSH-NCFG_Msg->NetEntryAddress) 
{ 

case OxOOOOOOOOOOOO:break; 
default :OthersState =BUSY; 

if (OthersMaxMacAdr <MSH-NCFG_Msg->NetEntryAddress ) 
OtherMaxMacAdr=MSH-NCFG_Msg->NetEntryAddress; 
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if (OthersMinMacAdr >MSH-NCFG_Msg->NetEntryAddress) 
OtherMinMacAdr =MSH-NCFG_Msg->NetEntryAddress; 
} 
} 
} 

void NetworkControlSubf rameStart ( ) { 
boolean xmt =FALSE; 
if (MSH-NENT_MsgQ->qLength ) { 

if (SponsorsState ==AVAILABLE) { 
if (OthersState !=BUSY) 

xmt =TRUE; 
} 
else if (SponsorsState ==POLLING) { 
if (OthersState !=BUSY) 

xmt =TRUE; 
else if ( ( (mayMacAdr >OthersMaxMacAdr) && (even supperframe) ) I I 
( (mayMacAdr <OthersMinMacAdr) && (odd supperframe))) 
xmt =TRUE; 
} 
} 
if (xmt) { 

Pkt*MSH-NENT_Msg =MSH-NENT_MsgQ->getHead ( ) ; 
MSH-NENT_MsgQ->dequeue (MSH-NENT_Msg) ; 
SendOutPkt (MSH-NENT_Msg, nextNetEntryslot ) ; 
} 

SponsorsState =UNAVAILABLE; 
OthersState =AVAILABLE; 
Other sMaxMacAdr =0x000000000000; 
OthersMinMacAdr =OxFFFFFFFFFFFF; 
} 

The individual subroutines are triggered by the transmission of a MSH-NENT packet, the reception of a MSH-NCFG 
packet and the start of a NetworkControl Subframe respectively. 

9.6 Network entry and synchronization 

Node initialization and network entry procedures in mesh mode are in some aspects different from those in PMP mode. 
A new node entering the mesh network obeys the following procedures. The whole entry pro-cess to the stage when the 
node can start scheduled transmissions can be divided into the following phases: 

1) Scan for active network and establish coarse synchronization with the network. 

2) Obtain network parameters (from MSH-NCFG messages). 

3) Open Sponsor Channel. 

4) Node authorization. 

5) Perform registration. 

6) Establish IP connectivity. 

7) Establish time of day. 

8) Transfer operational parameters. 

Each node shall contain a 48-bit universal MAC Address assigned during the manufacturing process. This is used to 
identify the node to the various provisioning servers during initialization and whenever performing authentication with 
a neighbour node. 

9.6.1 DLC management message tunnelling 

In Mesh networks during network entry certain DLC Message protocols take place between entities separated by 
multiple hops. In these cases the Sponsor Node shall relay the DLC Messages from the new node acting as the SS to the 
peer performing the duties of the PMP BS. The sponsor shall also relay the messages from the BS entity to the new 
node. 
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The Sponsor shall tunnel the DLC Messages received from the New Node (SS) listed in table 81 over UDP as shown in 
figure 9. to the entity performing the BS part of the protocol. The UDP source and destination port used for tunnelled 
messages shall be equal to 80216_UDP_PORT. The sponsor shall also extract the DLC messages from the UDP packets 
arriving from the BS entity and transmit them over the air to the New Node. 

Table 81 : DLC management message tunnelling over UDP 



Message 


Sponsor action 


Direction of 
message 


PKM-REQ: Auth Request 


Tunnel 


SS to BS 


PKM-REQ: Auth Info 


Tunnel 


SS to BS 


PKM-REQ: Auth Reply 


Extract 


BS to SS 


PKM-REQ: Auth Reject 


Extract 


BS to SS 


REG-REQ 


Tunnel 


SS to BS 


REG-RSP 


Extract 


BS to SS 


DSA-REQ 


Tunnel 


SS to BS 


DSA-RSP 


Extract 


BS to SS 


DSA-ACK 


Tunnel 


SS to BS 



IP header(s) 


UDP header 


Tunnel Subheader 


Message including headers 



Figure 9: DLC management message tunnelling message format 

The format of the Tunnel Subheader is defined in table 82. 

Table 82: Tunnel Subheader format 



Syntax 


Size 


Notes 


Tunnel Subheader() { 






Type 


8 bits 


= Reserved 

1 = HiperMAN DLC header 

2 to 255 = Reserved 


} 







Also, DLC messages may need to be tunnelled end to end in cases when the protocol takes place between peers 
separated by several hops. The packet format in figure 9 shall be used in these cases with the Tunnel Subheader format 
defined in table 82. 

9.6.2 Scanning and coarse synchronization to network 

On initialization or after signal loss, the node shall search for MSH-NCFG messages to acquire coarse synchronization 
with the network. Upon receiving a MSH-NCFG message the node acquires the network time from the Timestamp 
field. The node may have non-volatile storage in which all the last operational parameters are stored and shall first try to 
re-acquire coarse synchronization with the network. If this fails, it shall begin to continuously scan the possible 
channels of the frequency band of operation until a valid network is found. 

Once the PHY has achieved synchronization, the DLC Sublayer shall attempt to acquire network parameters. At the 
same time the node shall build a Physical Neighbour List (see clause 6.5.1). 
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Figure 10: Synchronization and networic entry - new node I 



9.6.3 Obtaining network parameters 



A node shall remain in synchronization as long as it receives MSH-NCFG messages. A node shall accumulate 
MSH-NCFG messages at least until it receives a MSH-NCFG message from the same node twice and until it has 
received a MSH-NCFG Network Descriptor with an operator ID matching (one of) its own if it has any. In parallel the 
new node shall update its Physical Neighbour List (see clause 9.5.1) from the acquired information. 

From the established physical neighbour list, the new node shall select a potential Sponsoring Node out of all nodes 
having the Logical Network ID of the node for which it found a suitable Operator ID. The new node then shall then 
synchronize its time to the potential sponsor assuming propagation delay after which it shall send a MSH-NENT 
NetEntryRequest including the Node ID of the potential sponsor. To determine a suitable transmission time, the node 
shall adhere to clause 9.5.2.2. 

Until the node has obtained a unique Node ID, it shall use temporary Node ID (0x0000) as Transmitter's Node ID in all 

transmissions. 

Once the Candidate Node has selected a Sponsoring Node, it shall use the Sponsoring Node to negotiate basic 
capabilities and to perform authorization. For that purpose the Candidate Node shall first request the Sponsoring Node 
to open Sponsor Channel for a more effective message exchange. 
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9.6.4 Opening sponsor channel 



Once the new node has selected one of its neighbours as the candidate Sponsoring Node it becomes a Candidate Node. 
To get further in the initialization procedure the Candidate Node shall request the candidate Sponsoring Node to 
establish a temporary schedule which could be used for further message delivery during the Candidate Node 
initialization. The temporary schedule requested is termed Sponsor Channel. 

The process is initiated by the Candidate Node which transmits a MSH-NENT NetEntryRequest message (a 
MSH-NENT message with Type set to 0x2) to the Sponsoring Node. 

Upon reception of the MSH-NENT NetEntryRequest message with the Sponsor Node ID equal to Node ID of its own, 
the candidate Sponsoring Node shall assess the request and either opens the Sponsor Channel or rejects the request. The 
response is given in a MSH-NCFG message with an Embedded Data as defined in clause 4.3.18.3. If the candidate 
Sponsoring Node does not advertise the Candidate Node's MAC Address in the sponsor's next MSH-NCFG 
transmission, then the procedure is repeated MSH_SPONSOR_ATTEMPTS times using a random backoff between 
attempts. If these attempts all fail, then a different Candidate Sponsoring Node is selected and the procedure repeated 
(including re-initializing coarse network synchronization). If the selected candidate Sponsoring Node does advertise the 
Candidate Node's MAC Address, it shall continue to advertise this MAC Address in all its MSH-NCFG messages until 
the sponsorship is terminated. 

Once the Candidate Node has received a positive response (a NetEntryOpen message) in from the candidate Sponsoring 
Node in the MSH-NCFG message, it shall acknowledge the response by transmitting a MSH- NENT NetEntryAck 
message (a MSH-NENT message with Type set to 0x1) to the Sponsoring Node at the first following network entry 
transmission opportunity. Before that the Candidate Node shall perform fine time synchronization. It makes a correction 
to its transmission timing by the Estimated propagation delay indicated in the embedded MSH-NCFG NetEntryOpen 
message. 

If the Sponsoring Node accepted the request and opened a Sponsor Channel, the channel is ready for use immediately 
after the transmission of the acknowledgement message. At the same the candidate Sponsoring Node becomes the 
Sponsoring Node. 

If the candidate Sponsoring Node embedded a MSH-NCFG NetEntry Reject, the new node shall perform the following 
action based on the rejection code: 

0x0: Operator Authentication Value Invalid 

The Candidate Node shall select a new candidate Sponsoring Node with a different operator ID. 

0x1: Excess Propagation delay 

The Candidate Node shall repeat its MSH-NENT:NetEntryRequest in the following network entry 
transmission opportunity to the same candidate Sponsoring Node. 

0x2: Select new sponsor 

The Candidate Node shall select a new candidate Sponsoring Node. 

If the candidate Sponsoring Node embedded neither MSH-NCFG NetEntryOpen nor MSH-NCFG NetEntryReject, the 
Candidate Node shall wait (with timeout time T2), for the next MSH-NCFG with NetEntryOpen from the candidate 
Sponsoring Node and resend the MSH-NENT NetEntryRequest on timeout. 

The Candidate Node and the Sponsoring Node use the schedule indicated in the NetEntryOpen message to perform 
message exchanges described in clauses 9.6.5 through 9.6.10. After this is completed, the Candidate Node shall 
terminate the entry process by sending a MSH-NENT NetEntryClose message to the Sponsoring Node in the network 
entry transmission immediately following a MSH-NCFG transmission from the Sponsoring Node, which shall Ack 
termination with MSH-NCFG NetEntryAck. 
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Figure 11 : Synchronization and network entry - new node II 
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Figure 12: Synchronization and networit entry - sponsor node 
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Table 83 displays the message transfer sequence during a successful network entry without repetitions or time-outs. 

Table 83: Network entry successful message exchange 



Sponsor node 








New node 


Nodes in network routinely advertise 
network with 
IVISH-NCFGiNetwork Descriptor 

[IVISH-NENT NetEntryRequest with own 

Node ID] 

Send NetEntryReject or NetEntryOpen 

with new node's MAC Address and 

schedule allocation for higher layer 

authentication and configuration 

exchange 




MSH-NCFG: 




[detecting MSH-NCFG messages with 
Network Descriptor] 
Attempt to enter the network 

Send ACK to confirm schedule 


<— 


Network Descriptor 

MSH-NENT: 
~ NetEntryRequest 

MSH-NCFG: 




NetEntryOpen 
MSH-NENT: 






NetEntryAcK 




Security sublayer and basic capability exchange operations 


Acknowledge closure of sponsorship 

And drop new node's IVIAC Address from 

subsequent MSH-NCFG messages 




MSH-NENT: 




After authentication and configuration, 
close entry procedure 

New node is now regular node in 
network 




NelEnlryClose 
MSH-NENT 






NetEntryAck 





9.6.5 Negotiating basic capabilities 

In Mesh Mode, basic capability negotiation is the same as for PMP systems and shall be performed after a logical link 
has been established. The node which requested the logical link shall act as the SS and initiate the SBC-REQ. 

9.6.6 Node Autinorization 

The new node shall perform authorization in an identical fashion as PMP systems. The new node shall act as the SS. 
The sponsor node upon reception of the Authent Info and Auth Request shall tunnel the messages as described in to the 
Authorization Node. The Authorization Node, acting as the BS, shall verify the SS Certificate of the new node and 
determine whether the new node is authorized to join the Network. Upon receiving tunnelled PKM-RSP DLC Messages 
from the Authorization Node the Sponsor shall forward the messages to the new node. 

9.6.7 Node Registration 

Registration is the process by which a node is assigned its Node ID. The sponsoring node upon reception of the 
REG-REQ shall tunnel the message as described in clause 9.6.1 to the Registration Node. Upon receiving tunnelled 
REG-RSP DLC Messages from the Registration Node the Sponsor shall forward the messages to the new node. The 
new node shall follow the procedure in figure 13. The Registration Node shall follow the procedure in figure 14. 
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Implementation 
dependent 




Establish 
Node ID 



Establish 
IP connectivity 



Figure 13: Registration - candidate node 



REG-RSP with 
Response = 1 



rWait for ^ 
REG-REQ W. 



REG-REQ 



Calculate HMAC { : 
Over REG-REQ 




REG-RSP with 
Response = 



Start T17 



Timeout T17 



Success 



Figure 14: Registration - registration node 



9.6.8 Establishing IP connectivity 



The node shall acquire an IP address using DHCP in a fashion identical to PMP systems. However, the procedure shall 
take place over the Sponsor Channel. 
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9.6.9 Establishing time of day 



The node shall retrieve the time of day in a fashion identical to PMP. However, the messages shall be carried over UDP 
in the Sponsor Channel. 



9.6.1 Transfer of operational parameters 



After successfully acquiring an IP address via DHCP the node shall download a parameter file using TFTP in a fashion 
identical to PMP systems. However, the node shall use the Sponsor Channel instead of the Secondary Management 
connection. 

Upon receiving tunnelled REG-RSP DLC Messages from the Provisioning Node the Sponsor shall forward the 
messages to the Candidate Node. 

The following additional configuration file encodings are available: 



Name 


Type 


Length 


Value 


Authorization Node 


22 


4 or 16 


IP Address of tlie Autliorization Node 


Registration Node 


23 


4 or 16 


IP Address of the Registration Node 


Provisioning Node 


18 


4 or 16 


IP Address of the Provisioning Node 



Using mesh, QoS is provisioned on a packet-by-packet basis using the Mesh CID. The connection-based QoS 
provisioning using the DSx messages are hence not used. A node obtains its AuthorizedQoSParamSet during the 
transfer of operational parameters. 

9.7 Privacy sublayer 

The privacy sublayer for Mesh mode is identical to that of PMP mode with the following exceptions. 

9.7.1 TEK exchange overview 

Upon achieving authorization, a Node starts for each Neighbour a separate TEK state machine for each of the S AIDs 
identified in the Authorization Reply message. Each TEK state machine operating within the Node is responsible for 
managing the keying material associated with its respective SAID. The Node is responsible for maintaining the TEKs 
between itself and all nodes it initiates TEK exchange with. Its TEK state machines periodically send Key Request 
messages to the Neighbours of the node, requesting a refresh of keying material for their respective SAIDs. 

The Neighbour replies to a Key Request with a Key Reply message, containing the BS's active keying material for a 
specific SAID. 

The Traffic Encryption Key (TEK) in the Key Reply is encrypted, using the node's public key found in the 
SS-Certificate attribute. 

Note that at all times the node maintains two active sets of keying material per SAID per neighbour. The life-times of 
the two generations overlap such that each generation becomes active halfway through the life of its predecessor and 
expires halfway through the life of its successor. A neighbour includes in its Key Replies both of an S AID's active 
generations of keying material. 

The Key Reply provides the requesting Node, in addition to the TEK, the remaining lifetime of each of the two sets of 
keying material. The receiving Node uses these remaining lifetimes to estimate when the Neighbour invalidates a 
particular TEK, and therefore when to schedule future Key Requests. The transmit regime between the initiating Node 
and the Neighbour provides for seamless key transition. 

9.7.2 Node Re-Authorization 

When re-authorizing with the network, the re-authorizing node shall tunnel the authorization messages as shown in 
figure 9 over UDP. 
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9.7.3 TEK usage 

For each of its SAIDs, the neighbour shall transition between active TEKs according to the following rules: 

• At expiration of the older TEK, the neighbour shall immediately transition to using the newer TEK for 
encryption. 

• The neighbour that generated the TEK shall use the older of the two active TEKs for encrypting traffic towards 
the Node that initiated the TEK. 

• The neighbour that generated the TEK shall be able to decrypt traffic from each node using either the older or 
newer TEK. 

For each of its authorized SAIDs, the initiator node shall use the newer of its two TEKs to encrypt traffic towards its 
neighbours with which it initiated a TEK exchange, and shall be able to decrypt traffic from the neighbour's traffic 
encrypted with either of the TEKs. 

9.7.4 Usage of operator shared key 

Each node shall be capable of maintaining two active Operator Shared Secrets. A node shall use the Operator Shared 
Secret to calculate a HMAC digest for the Key Request and Key Reply messages when exchanging TEKs with its 
neighbouring nodes. 

9.7.5 HMAC authentication l^eys and calculation of HMAC digests 

The HMAC_KEY_S shall be derived as follows: 

HM AC_KE Y_S = SHA(H_PAD_D I Operator Shared Secret) (17) 

where H_PAD_D = Ox3A repeated 64 times. 

HMAC digests calculated with the key HMAC_KEY_S shall be supported. When calculating the digest with this key 
the HMAC sequence Number in the HMAC tuple shall be equal to the Operator Shared Secret Sequence Number. 



9.8 Data scheduling 



Unlike the PMP mode, there are no clearly separate downlink and uplink subframes in the mesh mode. Each station is 
able to create direct communication links to a number of other stations in the network instead of communicating only 
with a BS. However, in typical installations, there will still be certain nodes which provide the BS function of 
connecting the mesh network to the backhaul links. In fact, when using mesh centralized scheduling (described below), 
these BS nodes perform much of the same basic functions as does the BS in PMP mode. Thus, the key difference is that 
in mesh mode all the SSs may have a direct links with other SSs. Further, there is no need to have direct link from a SS 
to the BS of the mesh network. This connection can be provided via other SSs. Communication in all these links shall 
be controlled by a centralized algorithm (either by the BS or "decentralized" by all nodes periodically), scheduled in a 
distributed manner within each node's extended neighbourhood, or scheduled using a combination of these. 



9.8.1 Distributed scheduling 



The stations with which a station has direct links are called neighbours and shall form a neighbourhood. A node's 
neighbours are considered to be "one hop" away from the node. A two-hop extended neighbourhood contains, 
additionally, all the neighbours of the neighbourhood. In the coordinated distributed scheduling mode, all the stations 
(BS and SSs) shall coordinate their transmissions in their extended two-hop neighbour-hood. 

The coordinated distributed scheduling mode uses some or the entire control portion of each frame to regularly transmit 
its own schedule and proposed schedule changes on a PMP basis to all its neighbours. Within a given channel all 
neighbour stations receive the same schedule transmissions. All the stations in a network shall use this same channel to 
transmit schedule information in a format of specific resource requests and grants. 

Coordinated distributed scheduling ensures that transmissions are scheduled in a manner that does not rely on the 
operation of a BS, and that are not necessarily directed to or from the BS. 
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Within the constraints of the coordinated schedules (distributed or centraHzed), uncoordinated distributed scheduHng 
can be used for fast, ad-hoc setup of schedules on a link-by-link basis. Uncoordinated distributed schedules are 
established by directed requests and grants between two nodes, and shall be scheduled to ensure that the resulting data 
transmissions (and the request and grant packets themselves) do not cause collisions with the data and control traffic 
scheduled by the coordinated distributed nor the centralized scheduling methods. 

Both the coordinated and uncoordinated distributed scheduling employ a three-way handshake. 

1) A MSH-DSCH:Request is made along with MSH-DSCH:Availabilities, which indicate potential slots for 
replies and actual schedule. 

2) A MSH-DSCH:Grant is sent in response indicating a subset of the suggested availabilities which fits, if 
possible, the request. The neighbours of this node not involved in this schedule shall assume the transmission 
takes place as granted. 

3) A MSH-DSCH:Grant is sent by the original requester containing a copy of the grant from the other party, to 
confirm the schedule to the other party. The neighbours of this node not involved in this schedule shall assume 
the transmission takes place as granted. 

The differences between coordinated and uncoordinated distributed scheduling is, that in the coordinated case, the 
MSH-DSCH messages are scheduled themselves in the control subframe in a collision free manner, whereas in the 
uncoordinated case, MSH-DSCH messages may collide. Nodes responding to a Request should, in the uncoordinated 
case, wait a sufficient number of minislots of the indicated Availabilities before responding with a grant, such that 
nodes listed earlier in the Request have an opportunity to respond. The Grant confirmation is sent in the minislots 
immediately following the first successful reception of an associated Grant packet. 

The relevance of the MSH-DSCH is solely defined by the message itself and entirely up to the station transmitting it. 



9.8.2 Centralized scheduling 



The schedule using centralized scheduling is determined in a more centralized manner than in the distributed scheduling 
mode. 

The network connections and topology are the same as in the distributed scheduling mode described in, but some 
portion of the scheduled transmissions for the SSs less than or equal to HOPRANGE_THRESHOLD hops from the BS 
shall be either defined by the BS or computed by the SSs themselves. HOPRANGE_THRESHOLD, may be determined 
at the system start up phase or may be dynamic according to considerations such as network density, the proximity of 
other BSs, and/or the dynamic characteristics of the traffic streams. 

In the basic form, the BS shall provide the schedule for all the SSs less than or equal to HOPRANGE_THRESHOLD 
hops from the BS. The BS determines the flow assignments from the resource requests from the SSs within the 
HOPRANGE_THRESHOLD hop range. Subsequently, the SSs themselves determine the actual schedule from these 
flow assignments by using a common algorithm that divides the frame proportionally to the assignments. Thus the BS 
acts just like the BS in a PMP network except that not all the SSs have to be directly connected to the BS and the 
assignments determined by the BS extends also to those SSs not directly connected to the BS but less than 
HOPRANGE_THRESHOLD hops from it. The SS resource requests and the BS assignments are both transmitted 
during the control portion of the frame. 

Centralized scheduling ensures that transmissions are coordinated to ensure collision-free scheduling over the links in 
the routing tree to and from the BS, typically in a more optimal manner than the distributed scheduling method for 
traffic streams (or collections of traffic streams which share links) which persist over a duration that is greater than the 
cycle time to relay the new resource requests and distribute the updated schedule. 

A simple example of the use of the centralized scheduling flow-mechanism in MSH-CSCH is provided. For the network 
in figure 15, the requested flows are shown. For simplicity of notation, the data rate is assumed to be the burst profile 
number. 

The link fractions shown in figure 16 are multiplied with 2^^°^^'^^^'^ Exponent+14 (ggg table 71) and with the Frame 
Duration, then rounded up to the nearest duration of a whole number of minislots required to transmit this fraction 
(including preamble). 
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Node ID: 
0x0666 




u 



^Node ID 
^0x02F0 




m 



Node ID: 
OxOlAB 




i Node ID Child Indexes 

0x0666 {I:[rui,rd,],2:[ru2,rd2]} 

1 0x02F0 {3:[r„3,rd3],4:[r„4,rd4]} 

2 OxOlAB { } 

3 0x0CD2 { } 

4 0X0123 {} 



jr^ jiPode ID 
OxOCD2 




f ^Node ID: 
[Jlfl 0x0123 




[ru,rd] is the burst profile, up and down 



Figure 15: MSH-CSCF schedule example 
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Figure 16: MSH-CSCH flow usage example 

The number of frames over which the CSCH schedule is valid is limited by the number of frames it takes to aggregate 
and distribute the next schedule. 

Each node uses the newly received schedule to compute its retransmission time (if eligible) and the last frame when a 
node will be receiving this schedule, as well as the time when the mesh BS sent it. To compute this, the node uses the 
routing tree from the last MSH-CSCF messages as modified by the link updates of the last MSH-CSCH message (which 
dictates the size of MSH-CSCH messages) and the following rules: 

The mesh BS transmits first in a new frame. 

Then, the eligible children of the mesh BS (i.e. nodes with hop count equal 1), ordered by their appearance in 
the routing tree, transmit. 

Then, the eligible children of the nodes from step 2 (i.e. nodes with hop count equal 2), also ordered by their 
appearance in the routing tree, transmit. 

. . .continue until all eligible nodes in the routing tree have transmitted. 

Nodes shall fragment their message if it does not fit entirely before the end of the control subframe and at least 
the preamble and one data symbol fit. 

All nodes are eligible to transmit the grant schedule, except those that have no children. 
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• If a node's order requires it to transmit immediately after receiving, a delay of MinCSForwardingDelay ^.s is 
inserted. 

Each node shall also compute the timing of the uplink requests. Uplink requests start in the last frame in which a node 
received the previous schedule. All nodes are eligible to transmit requests, except the mesh BS. The request 
transmission order is reverse in hopcount (i.e. largest hopcount first), but retains the transmission order as listed in the 
routing tree for nodes with the same hopcount. 

The number of frames over which the CSCH schedule is valid is limited by the number of frames it takes to aggregate 
and distribute the next schedule. The time between the first frame in which a node sends the request schedule and the 
last frame in which a node receives the new grant schedule marks the validity of the previous grant schedule 
(see figure 17). This validity time overrides the Frame schedule flag two frame usage at the end of the validity time. 
Note that MSH-CSCF messages may be sent after the last request is received and before the grant schedule is 
transmitted by the mesh BS. 

Validity of previous schedule 



Tree 
depth 



±-K^ 




MlnCSForwardDelav 



±-K^ 



±-K^ 



±-K^ 



Control subframe 



Data subframe 



Figure 17: MSH-CSCH schedule validity 



10 DLC support of PHY 



A compliant device shall conform to MAC Support of PHY mechanisms as defined in IEEE 802.16 [1], clause 6.3.7 
with the following exceptions nominated bellow. AAS optional mode is included in the referenced clause. 



10.1 Uplink timing 



Uplink timing is referenced from the beginning of the downlink subframe. The Allocation Start Time in the 
UL-MAP is referenced from the start of the downlink subframe and may be such that the UL-MAP references 
some point in the current or a future frame as provided in IEEE 802.16 [1], clause 6.3.7.5. The SS shall always adjust its 
concept of uplink timing based upon the Timing Adjustments sent in the RNG-RSP messages. 

n = (Rate* x Frame Duration) / 4 
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Figure 18: TDD frame structure 
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The Rate* is the nominal sampHng frequency (Fs). 

10.2 Uplink allocation 

For the PHY layer, the uplink bandwidth allocation map (UL-MAP) uses units of symbols and subchannels. 

1 1 Network Entry and Initialization 

The clause 6.3.9 from IEEE 802.16 [1] shall apply to PMP systems network entry and initialization. 
The fe)llowing clause shall apply instead of clause 6.3.9.5 from IEEE 802.16 [1]. 

11.1 Initial ranging and automatic adjustments 

Ranging is the process of acquiring the correct timing offset and power adjustments such that the SS's transmissions are 
aligned to the BS receive frame for OFDM PHY, and received within the appropriate reception thresholds. The timing 
delays through the PHY shall be relatively constant. Any variation in the PHY delays shall be accounted for in the 
guard time of the uplink PHY overhead. 

11.1.1 Contention based Initial ranging and automatic adjustments 

First, an SS shall synchronize to the downlink and learn the uplink channel characteristics through the UCD DLC 
management message. At this point, the SS shall scan the UL-MAP message to find an Initial Ranging Interval. The BS 
shall allocate an Initial Ranging Interval consisting of one or more transmission opportunities. For OFDM PHY, the size 
of each transmission opportunity shall be as specified by the UCD TLV, Ranging request opportunity size. 

For OFDM PHY, the SS shall put together a RNG-REQ message to be sent in an Initial Ranging Interval. The CID field 
shall be set to the non initialized SS value (zero). 

Ranging adjusts each SS's timing offset such that it appears to be collocated with the BS. The SS shall set its initial 
timing offset to the amount of internal fixed delay equivalent to collocating the SS next to the BS. This amount includes 
delays introduced through a particular implementation and shall include the downlink PHY interleaving latency, if any. 

When the Initial Ranging transmission opportunity occurs, the SS shall send the RNG-REQ message. Thus, the SS 
sends the message as if it were collocated with the BS. 

The SS shall calculate the maximum transmit signal strength for initial ranging, Pj^ jj^ MAX' from: 

Ptx.ir.max = EIRxPiR,^,, + BS.EIRP - RSS (18) 

where the EIRxPlR,max and BS_EIRP are obtained from the DCD, and RSS is the measured RSSI, by the SS, as 
described in the respective PHY. 

In the case that the receive and transmit gain of the SS antennae are substantially different, the SS shall use the 
equation: 

Ptx^ir.max = EIRxPiR,^ax + BS.EIRP - RSS + (G^^ss-Gj^ss)- (19) 

Where: 

• Gjjx SS is the SS receive antenna gain. 

• Gjx SS is the SS transmit antenna gain. 

In the case that the EIRxPjj^ ^.^^ and/or BS_EIRP are/is not known, the SS shall start from the minimum transmit power 
level defined by the BS. 
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NOTE 1: The EIRxPjj^ ^.^^ is the maximum equivalent isotropic received power, which is computed for a simple 
single antenna receiver as RSSjj^ ^.^^ - GANT_BS_Rx, where the RSSjj^ ^.^^ is the received signal 
strength at antenna output and GANT_BS_Rx is the receive antenna gain. The BS_EIRP is the equivalent 
isotropic radiated power of the base station, which is computed for a simple single-antenna transmitter as 
Pj^+ GANT_BS_Tx, where P-p^is the transmit power and GANT_BS_Tx is the transmit antenna gain. 

For OFDM PHY, the SS shall send the RNG-REQ at a power level below Ptx^IR_MAX, measured at the antenna 
connector. If the SS does not receive a response, the SS shall resent the RNG-REQ at the next appropriate Initial 
Ranging transmission opportunity at one step higher power level. If the SS receives a response containing the frame 
number in which the RNG-REQ was transmitted, it shall consider the transmission attempt unsuccessful but implement 
the corrections specified in the RNG-RSP and issue another RNG-REQ message after the appropriate backoff delay. 

If the SS receives a response containing its MAC Address, it shall consider the RNG_RSP reception successful. 

When BS detects a transmission in the ranging slot that it is unable to decode, it may respond by transmitting a 
RNG-RSP that includes transmission parameters but identifies the frame number and frame opportunity when the 
transmission was received instead of the MAC Address of the transmitting SS. 

Once the BS has successfully received the RNG-REQ message, it shall return a RNG-RSP message using the initial 
ranging CID. Within the RNG-RSP message shall be the Basic and Primary Management CIDs assigned to this SS. The 
message shall also contain information on RF power level adjustment and offset frequency adjustment as well as any 
timing offset corrections. At this point the BS shall start using invited Initial Ranging Intervals addressed to the SS's 
Basic CID to complete the ranging process, unless the status of the RNG-RSP message is success, in which case the 
initial ranging procedure shall end. 

If the status of the RNG-RSP message is continue, the SS shall wait for an individual Initial Ranging interval assigned 
to its Basic CID. Using this interval, the SS shall transmit another RNG-REQ message using the Basic CID along with 
any power level and timing offset corrections. 

The BS shall return another RNG-RSP message to the SS with any additional fine tuning required. The ranging 
request/response steps shall be repeated until the response contains a Ranging Successful notification or the BS aborts 
ranging. Once successfully ranged (RNG-REQ is within tolerance of the BS), the SS shall join normal data traffic in the 
uplink. In particular, state machines and the applicability of retry counts and timer values for the ranging process are 
defined in table 340 from IEEE 802.16 [1]. 

NOTE 2: The burst profile to use for any uplink transmission is defined by the Uplink Interval Usage Code 
(UIUC). Each UIUC is mapped to a burst profile in the UCD message. 

The message sequence chart (table 68) and flow charts from the reference define the ranging and adjustment process 
which shall be followed by compliant SSs and BSs. 
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Table 84: Ranging and automatic adjustment procedure 



Sponsor node 



New node 



[Time to send the Initial IVIaintenance 

interval] 

Send map containing Initial Maintenance 

IE with a broadcast CID. 



[Detect un-decodable RNG-REQ] 
Send response including Frame 
Number, Initial Ranging Opportunity 
Number, CID = 0. 



[Time to send the Initial IVIaintenance 

interval] 

Send map containing Initial Maintenance 

IE with a broadcast CID. 



[Detect decodable RNG-REQ] 
Allocate Basic and Primary Management 
CID and add Basic CID to poll list. 
Send response including SS MAC 
Address, Basic CID 



[time to send next map] 

send map with Station Management IE 

to SS using Basic CID 



Send ranging response 

Send periodic transmit opportunity to 
broadcast address 



-UL-MAP - 
RNG-REQ 

-RNG-RSP 



-UL-MAP - 
RNG-REQ 



-RNG-RSP 



-UL-MAP 



-RNG-REQ 
-RNG-RSP 



-UL-MAP 



Transmit ranging packet in contention 
mode with CID = 



[Recognize Frame Number/Qpportunity 
when RNG-REQ was send] 
Adjust parameters according to 
RNG-RSP 



Transmit ranging packet in contention 
mode with CID = 



[Recognize own MAC Address] 

Store Basic CID and adjust parameters 

according to RNG-RSP 



[Recognize own Basic CID] 

reply to Station Management opportunity 

poll 

Adjust local parameters 



NOTE 1 : The BS shall allow the SS sufficient time to have processed the previous RNG-RSP (i.e. to modify the 

transmitter parameters) before sending the SS a specific ranging opportunity. This is defined as SS Ranging 
Response Processing Time in table 340 from IEEE 802.16 [1]. 

NOTE 2: For multichannel support, the SS shall attempt initial ranging on every suitable uplink channel before moving 
to the next available downlink channel. 



On receiving a RNG-RSP instruction to move to a new downlink frequency and/or uplink channel ID, the SS shall 
consider any previously assigned Basic, Primary Management, and Secondary Management CIDs to be de assigned, 
and shall obtain new Basic, Primary Management, and Secondary Management CIDs via initial ranging and 
registration. 

It is possible that the RNG-RSP may be lost after transmission by the BS. The SS shall recover by timing out and 
reissuing its Initial RNG-REQ. Since the SS is uniquely identified by the source MAC Address in the Ranging Request, 
the BS may immediately reuse the Basic, Primary Management, and Secondary Management CIDs previously assigned. 
If the BS assigns new Basic, Primary Management, and Secondary Management CIDs, it shall make some provision for 
aging out the old CIDs that went unused. 
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12 Periodic ranging 



Periodic ranging shall conform to IEEE 802.16 [1], clause 6.3.10.2 as modified by IEEE P802.16/Corl [3] and 
IEEE P802.16e [4] shall apply to PMP systems periodic ranging. 



13 Bandwidth allocation and request mechanism 

A compliant device shall conform to bandwidth allocation and request mechanisms provided by IEEE 802.16 [1], 
clauses 6.3.6.1 to 6.3.6.4. 



14 Extended DLC Support 

A compliant device shall implement the clause 6.3, as defined in IEEE P802.16e [4] and IEEE P802.16/Corl [3]. 

15 Extended Privacy/Security 

A compliant device shall implement the clause 7, as defined in IEEE P802.16e [4] and IEEE P802.16/Corl [3]. 

Te DLC Support of OFDMA PHY 

A compliant device shall implement the MAC Support for OFDMA PHY mode as specified in clause 8.4 of 
IEEE 802.16 standard, in references [1], [3] and [4]. 

1 7 Parameters and constants 

A compliant device shall implement the relevant paragraphs in clauses 10.1, 10.2, 10.3.4 and 10.4, in references 
IEEE 802.16 [1], IEEE P802.16/Corl [3] and IEEE P802.16e [4]. 



18 TLV encoding 



A compliant device shall implement the relevant paragraphs in clause 11, in references IEEE 802.16 [1], 
IEEE P802.16/Corl [3] and IEEE P802.16e [4]. 
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